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ABSTRACT 


The  United  States  Navy  lacks  the  proper  and  efficient 
tools  to  evaluate/predict  the  performance  of  computer 
systems  during  the  early  design  phases  of  system 
development.  This  thesis  applies  state  of  the  art  techniques 
to  provide  a  methodology  that  can  assist  in  the 
evaluation/prediction  process  for  Naval  fire  control 
systems.  The  computer  system  evaluated  is  a  part  of  a 
modular  addition  to  existing  shipboard  gun  fire  control 
systems.  A  contract  for  the  Engineering  Development  (3D) 
phase  of  the  program  has  recently  been  awarded  to  industry. 
The  computer  system  architecture  is  evaluated  utilizing  a 
Petri-Net  simulation  which  is  best  suited  to  the  purpose  of 
concurrent  computer  system  performance  prediction.  The 
prediction  model,  described  herein,  accomplishes  the 
evaluation  with  the  results  being  utilized  to  recommend 
possible  performance  improvements  in  the  hardware  and 
software  to  the  U.S. Navy  Program  Office. 
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I  .   INTRODUCTION 
A.   BACKGROUND 

The  fire  control  system  evaluated,  the  SEAFIEE  program, 
is  presently  in  the  Engineering  Development  (ED)  phase  of 
the  weapon  system  development  process  with  system  deployment 
expected  some  time  during  the  mid  1980's.  A  Request  For 
Proposal  (RTF)  for  the  design  of  the  system  was  released  to 
industry  and  was  responded  to  by  a  numher  of  contractor 
teams.  A.  thorough  evaluation  of  these  proposals,  which 
included  technical,  management,  cost  and  schedule  factors, 
was  performed  over  a  ten  month  period  resulting  in  contract 
award  to  industry  during  1979.  The  contractor,  although 
provided  an  AN/UYK-20  computer  as  a  "baseline  processor,  was 
not  prohibited  from  using  additional  imbedded  processors  to 
support/enhance  his  design.  The  AN/UYK-20,  being  a  standard 
Navy  computer,  was  required  for  use  in  the  SEAFIRE  system  at 
this  time.  The  Program  Office,  however,  has  plans  to  replace 
the  AN/UYK-20  with  a  modern  computer  prior  to  the  SEAFIRE 
fleet  introduction.  These  plans  though  will  only  be 
implemented  if  the  AN/UYK-20  is  replaced  as  one  of  the  Navy 
standard  computers  and  if  the  Naval  Material  Command  allows 
it  to  occur. 

The  computer  architecture,  as  designed  by  the 
contractor,  represents  an  untested  real  time  combat 
subsystem.  This  thesis   attempts   to   evaluate   the   SEAFIRE 


8 


computer  architecture  and  provide  a  meaningful  input  to  the 
U.  S.  Navy  SEAFIR5  program  office  (Naval  Sea  Systems 
Command)  as  to  its  predicted  performance. 

3.   APPROACH 

The  first  step  to  accomplishing  this  goal  was  to  become 
familiar  with  the  present  design  status  of  the  computer 
architecture  and  to  develop  liason  with  its  designer.  The 
present  level  of  the  design  drove  the  evaluation  to  a 
modular  configuration,  as  would  be  expected  at  this  point  in 
the  design  process.  A  determination  was  then  made  to 
establish  the  performance  measures  on  which  to  measure  or 
estimate  the  performance  of  the  system. 

The  next  step  was  to  research  a  number  of  available 
methodologies  for  computer  architecture  performance 
prediction  and  to  select  the  one  methodology  determined  best 
suited  for  this  project.  The  model  selected  was  designed  by 
L.A.  Cox,  based  on  work  led  by  J.  Dennis  at  M.I.T.  and  other 
researchers.  This  model  was  developed  to  execute  on  a  non 
standard  CDC-7600  computer  system  and  thus  required 
considerable  effort  in  program  modification  to  enable  it  to 
run  on  the  PDP-11/50  minicomputer  at  NPS. 

The  remaining  work  consisted  of  developing  program 
representations  of  the  SEAFIRE  software  and  hardware  for  use 
in  the  simulator,  and  finally  in  the  analysis  of  the 
results.  A  number  of  assumptions,  which  were  required  due  to 


a  lack  of  information,  are  denoted  throughout  this  thesis.  A 
listing  of  the  final  version  of  the  Petri-Net  simulator  is 
contained  in  Appendix  A. 
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II.   THE  COMPUTER  SYSTEM  ARCHITECT 

A.  INTRODUCTION 

How  does  the  computer  system  architect  cope  with  the 
rapid  pace  of  computer  technology?  Eis  capability  to 
describe  the  hardware  at  specified  levels  in  an  efficient, 
interactive  manner  that  provides  a  dynamic  atmosphere  during 
the  life  of  computer  design  may  be  the  key.  This  chapter 
deals  with  a  spectrum  of  design  techniques  that  assist  the 
architect . 

B.  COMPUTER  SYSTEM  ORGANIZATIONAL  LEVELS 

According  to  Doty  and  Liposki  (11)  Von  Neumann's  1946 
paper,  "Preliminary  Discussion  of  the  Logical  Design  of  an 
Electronic  Computing  Instrument"  is  fundamentally  one  of  the 
most  significant  papers  in  computer  architecture  written; 
principally  because  it  was  written  15  years  before  the  term 
was  coined  (Von  Neumann  claimed  no  ideas  but  was  merely  a 
focal  point  for  them).  This  paper  outlined  the  four 
principle  units  required  of  a  general  computing  system;  the 
control  unit,  the  data  operator,  the  memory,  and  the  input/ 
output  unit.  These  units  form  the  conceptual  basis  of  almost 
all  current  computers. 

What  is  computer  architecture?  Ey  "computer 
architecture"  we  mean  the  abstract,   functional   description 
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of  a  computer  as  seen  by  a  machine-level  programmer,  that 
is,  everything  the  programmer  needs  to  know  to  write 
programs  that  run  effectively  on  the  computer  (i.e.,  the 
conceptual  structure  and  functional  behavior,  as  distinct 
from  the  organization  of  the  data  flow  and  controls,  the 
logical  design,  and  the  physical  implementation).  As  a 
result  of  the  changing  technologies  of  processors  and 
memories,  deficiencies  in  earlier  designs,  as  well  as 
innovations  in  networks  and  distributed  processing,  computer 
architecture  is  evolving  rapidly. 

In  addition  to  technology,  there  are  several  other  key 
factors  that  contribute  to  architectural  innovation?  most 
significant  are  increasingly  inexpensive  hardware  and  the 
rising  cost  of  software  (human  labor).  All  future  systems 
should  be  designed  with  consideration  of  these  and  other 
factors. 

A  good  system  can  be  defined  as  a  well-organized 
collection  of  components  chosen  to  meet  the  system  goal.  A 
modular  system  is  a  collection  of  these  component  modules. 
The  systems  are  the  largest  design  units,  and  subsystems  are 
convenient  intermediate-level  complexes  (18). 

One  system's  components  may  be  another's  systems,  in 
different  situations.  Therefore,  a  complex  system  design 
should  be  described  at  a  number  of  different  levels  which 
may  change  dynamically  as  the  design  proceeds  from  concept 
to  implementation. 
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1 .   Levels  of  Hardware  Design 

Bell  and  Newell  (2)  define  the  levels  in  the 
hierarchy  of  digital  computer  structures  largely  on  the 
basis  of  considering  the  different  activities  of  different 
technical  practitioners.  The  'institutional  positions'  of 
logic  designers  and  circuit  designers  are  used  as  evidence 
for  the  existence  of  distinct  levels.  Their  highest  level 
(the  PMS-Processor  Memory  System  level)  has  computers  as 
structures  and  processors,  memories  (storage)  etc.,  as 
components.  The  next,  or  programming  level,  sees  programs  as 
made  of  component  instructions,  operators,  etc.  The  three 
logic  design  levels  are  the: 

1)  Register  Transfer  Level  -  arithmetic  units  made  from 
registers,  controls,  data  operators? 

2)  Sequential  Switching  Circuit  Level  -  counters  made 
from  flipflops,  latches? 

3)  C omhinatorial  Switching  Circuit  Level  -  encoders, 
selectors,  iterative  nets  made  from  logic  gates. 

The  lowest  level  they  consider  is  the  circuit  level 
where  example  systems  (circuits)  are  amplifiers,  clocks  and 
gates  and  where  the  components  include  relays,  transistors, 
resistors,  diodes  and  delays.  The  essential  constraints  for 
the  notations  to  satisfy  are  ones  of  completeness, 
flexibility  and  brevity  (  high  informational  density)  (3). 

An  appropriate  criterion  might  he  to  identify  a  level  of 
design  with  a  design  description  (specification)  then: 
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"A  system  level  ...  is  characterized  by  a  distinct 
specification  for  representing  the  system  (that  is,  the 
components  modes  of  combination  and  laws  of  behavior).  These 
distinct  languages  reflect  special  properties  of  the  types 
of  components  and  of  the  way  they  combine  .  .  .  The  fact 
that  the  languages  are  highly  distinct  makes  it  possible  to 
be  confident  about  the  existence  of  different  levels'  (2) 

This  method  of  identifying  the  various  levels  of  system 
design  allows  one  to  identify  the  most  recently  emerged 
levels,  but  it  leads  to  a  significant  difficulty.  Whenever 
it  is  difficult  to  decide  whether  two  languages  are  highly 
distinct,  it  is  also  difficult  to  decide  whether  they  define 
different  levels.  Thus  it  seems  as  though  there  are  no 
effective  procedures,  even  in  principle,  for  counting  the 
number  of  distinct  levels  of  system  design.  The  number  of 
levels,  and  thus  the  extent  or  depth  of  the  levels,  are 
difficult  to  precisely  determine. 

This  view  introduces  a  new  notion:  the  span  (depth)  of  a 
level  is  commensurate  with  the  short  term  comprehension  of  a 
human  being.  That  is,  one  historical  reason  for  designing  a 
large  system  in  successive  stages  has  been  that  the  human 
designer  has  a  certain  limit  to  the  range  of  detailed 
consideration  which  he  can  instantaneously  handle 
effectively  (although  Cray/Amhdahl  developed  computers 
individually).  If  the  design  process  is  to  be  automated,  it 
might  be  initially  done  in  smaller  steps  _than  humans 
currently  handle  (for  the  machines  are  notoriously  inept  at 
handling  the  intuitive  associations  which  a  designer 
employs).  The  number  and  span  of  the  design  steps  has  always 
been  difficult  to  precisely  determine  and  we   should  expect 
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them  to  continue  to  change  in  the  future  (18).  It  is 
important  to  remember  that  all  our  experience  to  date  shows 
that  design  automation  cannot  rely  too  much  on  artificial 
methods;  the  human  has  to  stay  involved. 

The  design  specification  is  the  key  to  the  definition  of 
a  level.  The  language  defines  the  level;  is  the  tool  for 
designing  at  that  level?  expresses  the  components  and 
systems  of  the  level;  and  provides  the  documentation  for 
design  at  that  level.  The  lowest-level,  irreducible  units  of 
a  design  are  the  primitives  (words)  of  the  language;  the 
system  structures  designed  at  that  level  are  the  sentences 
of  the  language.  Preparing  a  design  at  a  given  level  means 
writing  a  statement  in  the  language  of  the  level.  The 
process  of  designing  an  entire  system  becomes  a  process  of 
carefully  translating  statements  in  one  higher-level 
language  to  successively  lower  levels. 
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C.   COMPUTER  HARDWARE  DESCRIPTION  LANGUAGES 

Computer  hardware  description  languages  (CHDL's)  can  be 
defined  as  languages  for  describing,  documenting, 
simulating,  and  synthesizing  digital  systems  with  the  aid  of 
a  computer  (23).  A  CHDL  can  be  used  to  describe  the  logic 
gates,  the  sequential  machines,  and  the  functional  modules, 
along  with  their  interconnection  and  their  control,  in  a 
variation  of  a  programming  language  tuned  to  the  overall 
needs  of  describing  hardware. 

1 .   Design  Automation 

Just  as  software  designers  use  high-level  languages  to 
express  algorithms  in  terms  of  language  statements,  so 
digital  hardware  designers  are  beginning  to  use  hardware 
description  languages  to  describe  the  digital  systems  they 
want  to  design  (24) . 

The  task  of  designing  a  digital  hardware  system  can  be 
considered  as  consisting  of  the  following  steps: 

1)  The  generation  of  a  system  diagram  from  the 
specifications  of  the  system  to  be  designed. 

2)  The  production  of  detailed  logic  diagrams  for  each 
subsystem. 

3)  The  partitioning  of  the  logic  diagram  into  general 
units . 
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4)  The  assignment  of  integrated  circuit  chips  for 
implementing  each  unit. 

5)  The  placing  of  chips  on  logic  cards  and  of  cards  on 
hoards,  and 

6)  The  interconnecting  of  the  chips. 

7)  The  testing  of  the  integrated  circuit  boards. 
Computers  have  been  widely  used  for  aiding  steps  4  to  7. 

A  total  design  automation  system  requires  that  steps  l.to  6 
be  automated.  CHDL's  can  be  used  for  aiding  system  and  logic 
design  as  well  as  partitioning  a  digital  system.  A  designer 
can  use  a  CHDL  to  express  his  design  and  leave  the  exacting, 
tedious,  uninteresting  details  to  a  computer  (23). 

The  process  of  automated  logic  design  may  consist  of 
the  following  steps: 

1)  A  designer  expresses  his  design  in  a  CHDL  by  writing 
a  program. 

2)  A  hardware  compiler  (translator)  checks  the  syntax, 
consistency,  etc.  of  the  language  statements  and  reports  the 
errors  to  the  designer  for  correction.  After  the  errors  are 
corrected,  the  translator  produces  a  data  base  to  be  used  by 
the  system  simulator  and  the  logic  synthesizer. 

3)  The  system  simulator  models  the  design  at  the  system 
level.  This  will  save  the  large  amount  of  computing  time 
used  for  simulating  everything  at  the  detailed  gate  level. 
If  the  system  performance  is  unsatisfactory,  the  design 
language  statements  are  modified.  If  the  performance  is 
satisfactory,  the  next  step  is  taken. 
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4)  The  logic  synthesizer  (a  program)  uses  the  data  base 
produced  by  the  translator,  accepts  the  types  and 
constraints  of  logic  components,  and  produces  a  logic 
diagram. 

Since  a  CHDL  constitutes  the  input  to  the  design 
automation  process,  it  plays  an  important  role  in  the  task 
of  achieving  automated  logic  and  system  design. 

2 .  Digital  Hardware  Languages  Under  Development 

A  number  of  digital  hardware  languages  exist  today  and 
are  in  use  by  industry  as  well  government  sources.  One  of 
the  most  recent  uses  in  the  military  was  for  the  selection 
of  the  Computer  Family  Architecture  (CFA)  (1,20).  This  was  a 
joint  DOD  effort  aimed  at  providing  defense  systems 
developers  with  a  software  compatible  family  of  military 
computers  at  varied  levels  of  performance  that  have 
extensive  systems/support  hardware.  One  facet  of  the 
selection  process  was  that  the  measurements  and  tests  of 
hardware  candidates  were  made,  not  on  the  various  computers 
as  physical  objects,  but  on  their  formal  descriptions 
expressed  in  IS?L  (Instruction  Set  Processor  Language)  (2). 

This  was  the  first  time  that  the  architectures  of 
commercially  viable  computers  were  described  in  a  formal 
language,  the  description  compiled,  and  then  used  to  drive  a 
simulator,  executing  benchmarks  and  diagnostic  machine 
language   programs.  A  valid  sign  for  future  users  is  that  it 
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was  generally  accepted  by  industry,  military  and  government. 
What  other  methods  have  been  developed  since  the  above? 
The  remainder  of  this  section  covers  several  of  the  efforts 
presently  being  developed  as  a  result  of  the  Working  Group 
of  the  Conference  on  Computer  Hardware  Eescription 
Languages. 

a.  Consensus  language  (CONLAN) 

CONLAN  is  a  consensus  hardware  description  language 
capable  of  representing  hardware  at  several  distinct  levels 
of  detail  (15).  The  range  of  language  levels  suggests  a 
family  of  languages  that  share  a  common  basic  syntax  and  are 
rooted  in  a  common  semantic  base. 

Guidelines  laid  down  for  the  language  follow: 

A.  CCNLAN  must  support  design,  description, 

and  simulation  of  at  least  the  following  classes  of  systems: 
gate  networks,  register  networks,  processors,  memories, 
processor  systems.  Each  class  has  been  fully  defined. 

B.  Any  system  may  be  displayed  via  either  (a)  a 
network  structure  description  or  (b)  a  behavior  description. 

C.  CONLAN  is  to  service: 

1.  Computer  architects  and  logic  designers 
for  purposes  of  trade-off  exploration  and 
optimization,  design  verification,  and 
design  documentation. 

2.  Systems,  micro,  and  applications  program- 
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mers  . 

3.  Electronics  production  engineers. 

4.  Maintenance  engineers. 

D.  CONLAN  syntax  and  semantics  must  support: 

1.  Veil-defined  descriptions 

2.  Machine  parsing,  interpretation  and 
simulation  with  error  detection  (strong 
typing  has  been  adopted) 

3.  Comprehension  of  complex  system  structure 
and  function 

4.  Division  of  design  efforts 

5.  Control  over  the  level  of  abstraction  at 
which  subsystems  are  described. 

6.  Simulation  control 

E.  CONLAN  will  be  evaluated  in  terms  of 
benchmarks  such  as:   standard   function   declarations,   time 
operator  declarations,  integrated  circuit  descriptions  (long 
list,    including   microprocessors),    design  descriptions 
(another  long  list  including  a  multiprocessor  system). 

The  details  of  CONLAN  (i.e.  BNF  grammer,  etc.)  are 
contained  in  (15).  Since  CONLAN  is  still  under  development, 
additional  information  is  available  only  from  the  working 
committee  which  is  developing  the  language. 

b.  Digital  Design  Language  Translator  (DDLTRN) 

Today,  the  greater  complexity  of  systems,  the  desire  for 
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short  design  cycles  and  error-free  designs,  and  the  use  of 
array  logic  all  suggest  the  need  for  machine  assistance  in 
the  logic  design  activity  (8).  DDL  is  a  block  oriented, 
statement  register  transfer  language  for  the  description  of 
digital  hardware.  DDLTRN  is  a  program  that  translates  a  DDL 
description  of  a  digital  system  to  Boolean  equations  and 
register  transfer  statements  suitable  for  driving  a 
companion  simulator  program  DDLSIM  (6,9).  DDLTRN  is  written 
in  the  IFTRAN  (a  structured  FORTRAN)  language  (16). 
Translation  consists  of  replacing  the  syntax  of  more 
abstract  language  constructs  with  more  explicit  syntax, 
yeilding  Boolean  equations  and  IF-THEN  conditioned  register 
transfer  statements. 

As  mentioned  earlier,  DDLSIM  is  a  program  for  simulating 
digital  systems  described  using  DDL  (7).  DDLSIM  does  very 
extensive  error  checking  of  described  systems,  simulation 
control  cards,  (same  system  with  different  data  sets  and/or 
parameters),  and  the  simulation  process  itself.  DDLSIM 
permits  multiple  simulation  runs  within  one  job  in  order  to 
either  verify  the  system  design  or  study  its  behaviors  under 
different  conditions. 

DDLTRN/SIM  and  CONLAN  are  two  examples  of  the  growing 
number  of  design/automation  aids  available  today.  These 
CHDLs  put  the  the  architecture  community  in  the  position  to 
explore  and  develop  needed  design  automation  tools.  Since 
Dietmeyer  is  a  member  of  the  above  committee,  it  would  be 
expected   that   many  of  his  ideas  will  be  incorporated  into, 


21 


or  provide  the  "basic  groundwork  for  future  efforts. 
D.   INTEGRATED  CIRCUIT  (IC)  DESIGN 

Ever  since  integrated  circuit  designers  began  to  put 
thousands  of  transistors  onto  a  single  chip,  the  cost,  in 
terms  of  human  labor,  required  to  lay  out  the  circuit  has 
been  extremely  high.  Although  hardware  has  reached  a  point 
of  being  considerably  cheaper  than  software,  the  Department 
of  Defense  (DOD)  requirements  for  special  purpose,  limited 
market  chips  has  seen  its  time.  The  need  for  good  design 
automation  in  the  area  of  integrated  circuit  layout  is 
severe.  What  is  needed,  and  what  is  evolving,  are  design 
techniques  which  free  the  designer  from  the  tedious  aspects 
of  IC  design  and  allow  him  to  concentrate  on  the  more 
creative  and  necessarily  human  side  of  the  design  process. 

Using  traditional  methods,  large  scale  integrated 
circuit  lay  out  is  a  tedious,  time  consuming  and  error-prone 
process.  For  commercial  use,  where  literally  millions  of 
identical  chips  are  sold  each  year,  the  cost  to  do  this  has 
not  been  a  problem.  Eut  for  the  DOD  it  is  becoming  an 
increasingly  significant  problem;  especially  since  the  DOD 
market  for  ICs  comprises  only  about  7%  of  the  total  IC 
market  and  because  environmental  and  other  constraints  are 
becoming  more  severe  (16).  The  overall  goal  of  an  IC  design 
is  to  pack  as  much  circuity  as  possible  into  the  smallest 
possible   amount    of    "chip   real-estate" ( IC   density), 
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therefore,  higher  production  yields  may  he  obtained. 

1 .   The  Problem  and  the  Proposed  Solution 

At  present,  when  a  company  designs  large  scale 
systems,  there  are  often  delays  of  months  or  even  years  in 
the  development  of  a  prototype  IC  and  the  price  for  a  single 
chip  ranges  from  one  quarter  to  half  a  million  dollars,  the 
DOD  is  forced  to  revert  to  using  older  technology.  This, 
coupled  with  the  typical  eight  to  fourteen  year  system 
development  cycle  of  large  computer  systems  (examples 
include  AEGIS,  TACEIRE  and  CDC  STAR  100),  has  created  quite 
a  military  dilema.  Add  to  these  problems  the  stringent 
requirements  for  MIL-SPEC  qualification,  fault-tolerance, 
built-in  test,  high  clock  rates,  and  the  use  of  advanced 
design  concepts  for  af f ordability ,  causes  the  required  chips 
not  be  ready  for  several  years  and  when  available  are 
extremely  high  in  cost  to  the  user. 

A  new  DOD  (Tri-Service )  program  known  as  Very  High  Speed 
Integrated  Circuits  (VHSICs)  began  at  the  start  of  FY  ?9  and 
is  a  six  year  effort  initially  budgeted  for  in  excess  of 
$200  million  dollars.  Program  goals  require  a  processing 
throughput  capability  for  computers  of  between  130  to  1000 
times  greater  than  presently  exists. 

The  overall  purpose  of  the  DOD  program  is  to: 

Advance  introduction  of  VHSIC  into  military  systems 
by  at  least  five  years  ahead  of  present  projections 
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.  Focus  industry  attention  on  DOD  requirements   through 
the  establishment  of  distinct  goals  and  funding  infusion 

Make  the  latest  state-of-the-art  devices  available 
for  military  use  in  advance  of  commercial  exploitation, 
thereby  reversing  the  present  two  to  five  year  lag  between 
commercial  development  and  military  availability 

.  Advance  IC  technology  beyond  the   limits   of   optical 
litho-  graphy  to  submicron  dimensions 

Replace  over  fifty  or  more  present  ICs  with  one  IC, 
thereby  providing  at  least  a  ten-fold  reduction  in  the  size, 
weight,  power  consumption  and  failure  rate  with  accompanying 
savings  in  both  initial  and  life  cycle  costs  of  present 
military  computer  processing  systems. 

Provide  ICs  with  100  times  the  processing  throughput 
capability  of  present  ICs  (16). 

By  meeting  the  above  stated  goals,  the  DOD  expects  to 
achieve  affordable  chips,  reduce  potential  supply  and 
logistics  problems  and  maximize  system  reliability.  The 
improved  architectural  and  design  concepts  should  result  in 
a  limited  chip  set  with  broad  applicability  to  military 
systems . 

2 .   Can  the  Computer  Architect  Exploit  this  Advance? 

Despite  these  advances  that  semiconductor  technology 
has  created,  the  question  arises  as  to  whether  the  computer 
architect  can  exploit  these  with  proven   design  methods   of 
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his  own.  A  number  of  approaches  have  teen  actively  pursued 
over  the  last  fev  years  (see  previous  section).  However, 
there  are  not  currently  the  languages,  operating  systems  and 
design  methods  needed  to  effectively  employ  the  new  LSI 
devices  which  can  now  he  produced.  We  would  like  to  he 
limited  only  by  economic  factors,  not  technical  or 
theoretical  factors.  A  hope  is  that  a  new  dimension  for  the 
architecture  of  computer  systems  will  emerge  from  these 
design  methods  so  that  LSI  design  methodology  can  be  used 
effectively.  There  is  a  need  to  proceed  slowly  and  rather 
cautiously  and  to  introduce  somewhat  more  general  purpose 
description  languages  selectively. 

The  military  system  cannot  afford  these  time  delays  and 
much  effort  is  being  pursued  to  shorten  this  cycle  and  to 
obtain  industry  input  earlier.  A  major  directive,  Office  of 
Management  and  Budget  Directive  0MB  A:109  (17),  has  as  a 
major  goal,  industry  involvement  in  system  development 
earlier  in  the  conceptual  development  phase.  This  thrust, 
combined  with  the  availability  of  the  tools  discussed  in 
this  section  on  design  automation  and  those  to  be  covered  on 
architecture  evaluation  could  be  implemented  as  Concept 
Development  Phase  evaluation  techniques.  The  impact  would  be 
to  provide  state-of-the-art  computer  designs  at  lower  costs 
with  the  added  effect  of  shortening  the  entire 
development/procurement  cycle. 
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E.   SUMMARY 

This  section  has  provided  the  oasis  to  understand 
computer  architecture  as  viewed  by  different  practitioners 
and  how  methods  are  being  developed  to  assist  in  early 
design  phases.  These  techniques  can  assist  the  DOD  in 
realizing  better  structured  hardware  and  to  accomplish  the 
tasks  required. 

The  next  section  further  defines  the  methodology  phases 
of  architecture  evaluation  used  to  enhance  the  automated 
design  techniques  covered. 
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Ill .   COMPUTER  PERFORMANCE  EVALUATION 

A.  INTRODUCTION 

Computer  performance  evaluation  attempts  to  provide  a 
methodology  for  examining  the  adequacy  of  a  computer  system 
as  it  serves  or  will  serve  the  needs  of  its  users.  In  this 
context,  performance  may  be  interpreted  as  the  technical 
equivalent  of  the  notion  of  value  to  the  user.  In  other 
words,  the  performance  evaluation  activities  can  he  regarded 
as  those  technical  activities  whose  purpose  is  the 
assessment  of  performance  (how  well  the  system  works)  (12). 
This  chapter  discusses  different  levels  of  performance 
evaluati  on. 

B.  PURPOSES  OF  PERFORMANCE  EVALUATION 

In  general,  there  are  three  major  motivations  for 
performance  evaluation:  selection  evaluation,  performance 
prediction  and  performance  monitoring.  These  purposes  can  be 
classified  along  several  dimensions  according  to  their 
specific  objectives.  As  with  many  other  system  evaluation 
techniques,  these  classifications  are  only  convenient  ways 
of  organizing  a  repertoire  of  knowledge  in  to  a  framework 
which  can  be  more  easily  understood.  The  dividing  lines 
between  categories  are  somewhat  unclear,  but  are  utilized 
for  lack  of  a  better  method. 
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JL.      Selection  Evaluation 


One  of  the  most  frequent  reasons  for  initiating  an 
evaluation  is  to  include  performance  as  a  'decision 
criteria"  in  computer  system  or  digital  electronics  system 
decisions  for  a  specified  operational  requirement.  The 
section  on  SEAFIRE  provides  a  description  of  such  a  system 
along  with  an  overview  of  the  original  evaluation  guidelines 
for  procurement  of  the  system.  It  should  be  recognized  that 
the  computer  system  was  only  a  subsystem  in  the  context  of 
the  SEAFIRE  hardware,  which  in  turn  was  but  a  single  factor 
in  the  total  weapon  system  procurement  (cost,  management, 
etc.  were  also  weighted  as  portions  of  system  value).  Each 
competitive  contractor  teams  proposal  may  have  contained  one 
or  more  superior  subsystems,  but  were  judged  to  have  fallen 
short  in  many  other  areas.  For  example,  one  of  the  losing 
contractors  may  have  had  a  better  computer  subsystem,  but 
poorer  subsystems  in  the  other  areas.  Additionally,  his 
management  approach  or  cost  proposal  may  not  have  been  as 
good  as  the  winners'.  Therefore,  the  weapon  system  design 
selected  may  not  necessarily  provide  the  U.S  Navy  with  the 
"best"  computer  architecture  available,  but  the  overall 
system  approach  is  probably  the  soundest  and  the  most  cost 
effective  for  the  Mavy. 

In   general,   selection   problems  may  be  classified  into 
the  following  categories  (12). 


28 


a.  Processing  mode  selection 

b.  Vendor  selection 

c.  Installation  Selection 

d.  System  Component  Selection 

e.  Application  Program  Selection 

A  definition  of  each  category   is   not   provided   since 
content  is  clear. 


the 


2.   Performance  Pro  lection 

This  evaluation  technique  may  he  the  least  frequently 
used.  The  problem  here  is  to  estimate  the  performance  of  a 
system  not  yet  in  existance  (in  some  state  of  design).  Thus, 
the  evaluation  is  oriented  toward  a  new  system  design,  both 
hardware  and  software.  The  evaluation  technique  pursued  in 
this  research  is  encompassed  within  this  category.  The 
performance  evaluation  of  algorithms  run  on  a  particular 
computer  architecture  is  mostly  concerned  with  performance 
prediction  and  is  restricted,  in  general,  to  some  form  of 
computer  modeling  or  simulation.  In  section  V  a  method  of 
conceptually  representing  computer  systems  by  use  of  a 
concurrent  control  system  model  is  explained.  This  method 
forms  the  basis  for  the  performance  prediction  system 
developed  by  Cox  (4)  and  modified  for  use  here. 
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3.   Performance  Monitoring 

Cnce  a  system  is  operational,  monitoring  provides 
data  on  the  actual  performance  of  the  system.  The 
performance  statistics  that  may  be  obtained  while  executing 
test  programs  aid  in  future  equipment  procurement  decisions 
and  are  employed  by  the  system  user  for  system  tuning;  in 
forecasting  the  impact  of  changes  in  the  system  (either  in 
reconfiguring  the  hardware  or  in  improving  executed  software 
modules) .  The  imuact  of  future  technology  and  computer 
architecture  will  greatly  affect  performance  monitoring  at 
all  levels  of  the  computer  system.  Internal  and  external 
instrumentation  will  provide  data  accessible  to  the 
performance  evaluator.  A  distinction  should  be  understood 
here  between  performance  monitoring  (continuous)  and  an 
evaluation  study.  Continuous  monitoring  is  usually  performed 
for  a  substantial  portion  of  the  lifetime  of  the  existing, 
running  system.  Its  objective  is  to  keep  the  system's 
performance  under  observation  in  order  to  detect  performance 
problems  as  soon  as  they  arise.  An  evaluation  study  is 
generally  much  more  limited  in  time  and  is  usually  triggered 
by  the  identification  of  a  performance  problem  or  the 
suspicion  of  its  presence.  The  following  sections  delineate 
the  evaluation  aspects  at  various  hardware  levels. 
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a.  At  the  Chip  Level 

With  the  trend  to  large  scale  circuit  integration, 
performance  evaluation  through  hardware  instrumentation  is 
becoming  less  flexible.  The  number  of  leads  remain  constant 
or  decrease  while  the  number  of  functions  increase  with  the 
consequence  of  fewer  test  points  per  function  being 
available.  Since  the  cost  per  gate  has  reduced  by  a  factor 
of  100  over  the  last  ten  years,  it  is  now  economically 
feasible  to  devote  some  of  the  circuitry  in  these  chips  to 
auxiliary  functions  such  as  performance  monitoring.  This 
will  provide  built-in  data  analysis  without  the  addition  of 
any  hardware . 

b.  At  the  CP-I/0  Level 


At  this  level  the  large  -  scale  integrated  circuit 
chips  will  be  interconnected  in  various  ways  to  implement 
the  hardware  instrumentation.  Chips  such  as  microprocessors 
will  be  used  to  do  the  actual  work  in  this  area.  As  with  the 
previous  level,  lack  of  test  points  is  a  major  problem; 
microprogramming  causes  an  elimination  of  some  probe  points. 
Also,  more  test  points  are  lost  due  to  the  trend  towards 
eliminating  peripheral  channels.  Costs  can  be  reduced  by 
integrating  device  control  units  into  the  processor  and 
transferring  information  as  serial  bit  streams. 


c.  At  the  System  Level 

At  this  level,  built-in  hardware  monitors  may 
provide  additional  assistance.  The  performance  statistics 
collected  by  the  associated  hardware/software  can  be  time 
correlated  through  the  use  of  other  microprocessors.  The 
result  is  two  fold:  first  to  reduce  the  overhead  of  whatever 
software  instrumentation  is  still  required,  and  second  to 
eliminate  the  need  for  external  monitoring  devices.  The 
important  advance  at  this  level  is  that  performance  data 
will  be  stored  under  the  system's  database  management  system 
which  will  allow  for  on-line  display  of  performance 
monitoring  data.  The  data  is  therefore  available  for  on-line 
input  to  various  scheduling  algorithms  used  to  "fine  tune" 
the  system  dynamically.  A  major  draw-back  to  this  method  may 
be  that  the  evaluation  schemes  will  have  difficulty  in 
dealing  with  the  virtual  environment  of  present  and  future 
systems.  An  additional  way  would  be  the  tendency  to  less 
secure  systems  because  of  the  required  critical  parameters 
associated  with  the  performance  evaluation  schemes. 

d.  At  the  Network  Level 

Distributed  processing  is  the  functional 
distribution  and  cooperative  processing  of  user  applications 
among  nultiple,   separately  located  computer  systems  of  the 
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same  and/or  different  size  and  characteristics.  The 
decreasing  cost  of  hardware  coupled  with  the  increasing 
performance  of  distributed  systems  offers  some  advantages  to 
performance  evaluation  at  this  level.  Performance  data  can 
he  collected  locally  at  each  site  and  transmitted  to  a 
central  cite  for  evaluation  and  will  provide  a  baseline  for 
network  tuning.  From  a  global  viewpoint  though,  more  factors 
must  be  taken  into  account  to  assure  that  suboptimization 
does  not  occur. 

C.  SUMMAPY 

This  chapter  has  provided  a  partial  outline  of 
performance  evaluation  techniques  used  for  computer 
evaluation.  Other  specific  techniques  such  as  benchmark, 
kernel,  analytical  model,  synthetic  programs,  etc.  are 
available  but  not  discussed  here.  A  thorough  discussion  is 
provided  in  reference  4.  These  areas  are  selection 
evaluation,  performance  prediction  and  performance 
monitoring.  The  DOD  requires  a  more  defined  approach  to  all 
these  areas  but  is  most  lacking  in  performance  prediction 
techniques . 

The  next  section  describes  a  predictive  method  which 
will  be  applied  in  this  thesis. 
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IV.   SEAFIRE  (ELECTRO-OPTICAL  FIRE  CONTROL  SUBSYSTEM) 

A.  INTRODUCTION 

This  section  provides  an  overall  description  of  the 
SEAFIRE  Program  and  outlines  its  intended  capabilities. 
SEAFIRE  is  presently  in  the  Engineering  Development  (ED) 
phase  of  the  weapon  system  development  process  with  system 
deployment  expected  sometime  during  the  mid  1980's.  A 
Request  for  Proposal  was  released  to  industry  and  was 
responded  to  by  a  number  of  contractor  teams.  A  thorough 
evaluation  of  these  proposals,  which  included  technical, 
management,  cost  and  schedule  factors,  was  performed  over  a 
ten  month  period  resulting  in  contract  award  to  industry 
during  1979.  The  computer  subsystem  section  of  the  RF?  is 
more  formally  described  and  the  computer  architecture 
response  to  this  section  is  described  at  the  component 
level . 

B.  SEAFIRE  DESCRIPTION 

1 .  Subsystem  Definition 

SEAFIRE  is  an  electro-optical  fire  control  subsystem 
modular  addition  to  shipboard  gun  fire  control  systems 
(GFCS).  This  addition  will  allow  control  of  the  guns  and 
gunfire   by   the   GFCS   when   ship's   sensors   can  designate 
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certain  targets  to  SEAFIRE  for  which  an  electro-optical 
sensor  is  effective.  SEAFIRE  will  also  allow  uninterrupted 
operation  of  GFCSs  when  the  GFCS  sensors  are  ineffective 
because  of  performance  degradation  or  are  incapacitated  by 
eauipment  failure,  casualty  or  tactical  limitations.  SEAFIRE 
shall  consist  of  an  optical  director  (above  deck)  and 
control,  test  and  display  units.  As  a  subsystem  integrated 
with  a  GFCS,  SEAFIFE  will  perform  the  following  functions 
against  Surface  Major  Combatants,  shore 
vehicles /installations ,  surface  coastal  defense  craft  and 
river  patrol  craft(22): 

a.  Target  Detection-SEAFIEE  will  provide  the 
GFCS  with  day  and  night,  passive  electro-optical  imaging  for 
detection,  manual  and  automatic  angle  tracking,  and  active 
laser  rangef inding.  SEAFIRE  will  be  capable  of  performing 
these  operations  against  sea,  surface  and  shore-based 
targets  which  can  be  engaged  by  the  GFCS  during  electronic 
countermeasures  (ECM),  electro-optical  countermeasures 
(EOCM)  and  Emission  Control  (EMCON)  conditions. 

b.  Target  illumination  -  Once  SEAFIRE  has 
established  track  of  a  target,  SEAFIRE  will  be  capable  of 
providing  laser  target  illumination  for  laser-guided 
ordinance. 

c.  Other  fire  control  functions  -  SEAFIRE  will 
be  capable  of  tracking  reference  points  (landmarks,  buoys, 
etc.)  to  provide  navigation  data  to  the  GFCS  for  indirect  or 
offset  firing.  SEAFIRE  shall  be  capable  of  sharing  its   line 
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of   sight   (LOS)   to   the   LOS  of  the  GFCS  radars  for  target 
identification  and  check  sighting. 

d.  Ancillary  Functions  -  When  not  employed  as  a 
target  tracking  sensor  for  fire  control,  the  inherent 
capabilities  of  SEAFIRE  will  provide  ancillary  functions 
including,  hut  not  limited  to:  detection  of  chemical  agent 
clouds,  and  aiding  in  navigation,  station  keeping,  friendly 
operations,  surveillance,  intelligence  collection,  swimmer 
detection  and  underway  replenishment. 

In  addition,  SEAFIRE  will  he  capable  of  being  configured 
as  a  SEAFIRE  independent  GFCS  for  applications  aboard  ships 
on  which  no  other  GFCS  exists.  As  a  SEAFIRE  independent 
GFCS,  SEAFIRE  should  be  capable  of  performing,  in  addition 
to  a,  b,  c,  and  d  above,  all  functions  necessary  to  engage 
and  direct  gunfire  against  all  trackable  targets.  These 
functions  will  include,  but  not  be  limited  to:  direct 
acceptance  of  tactical  information,  interface  with  ship's 
stable  reference,  generation  of  gun  orders  and  interface 
with  gun  mounts. 
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2.  SEAFIRE  General  Description 

SEAFIRE  will  be  comprised  of  a  director,  passive 
imaging  sensors,  laser  transmitter  and  receiver,  as  well  as 
support,  display,  and  control  devices.  SEAFIRE  controls  and 
display  will  be  integrated  into  the  consoles  in  the  MARK  86 
and  92  GFCS  applications.  The  controls  and  display  in  the 
MAPI  63  GFCS  application  will  be  configured  as  a  drawer  of 
the  AN/SPG-53  radar  console.  SEAFIRE  will  have  an 
independent  console  in  the  SEAFIRE  independent  GFCS.  The 
following  major  component  list  represents  the  SEAFIRE 
baseline(21) : 

Director 

Laser  Rangef inder/Illuminator  (LR/I) 

Thermal  Imaging  Sensor  (TIS) 

Television  Sensor  (TVS) 

Computer,  Computer  Program,  and  Related  Equipment 

Maintenance  Panel 

Interconnecting  Cables 

Remote  Video  Displays 

Support  and  Test  Equipment 

Console 

Automtic  Video  Tracker  (AVT) 

Interface  Module 

Video  Character  Generator 

Video  Processor 
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Real  Time  Clock 

SEAFIRE   is   depicted   in   the   functional   block  diagram  of 
Figure  1 . 

3.  SEAFIRE  Operational  and  Organizational  Concepts 

SEAFIRE  will  be  used  in  conjunction  with  the  MARK 
86,  68  (digital),  92  and  SEAFIRE  independent  GFCSs  with 
ship's  interface  being  provided  through  the  GFCS,  except  in 
the  SEAFIRE  independent  GFCS.  In  all  applications,  SEAFIRE 
mode  structure  and  controls  should  be  designed  to  minimize 
operator  work  load.  The  following  list  represents  some 
SEAFIRE  operational  concepts. 

a.  For  engagements  in  which  the  fire  control 
radars  can  provide  adeauate  track  data,  SEAFIRE  may  be  used 
predominantly  in  DESIGNATION/SLAVE  for  check-sighting, 
threat  evaluation,  spotting  corrections  for  fall  of  shot, 
and  kill/damage  assessment. 

b.  For  engagements  in  which  the  fire  control 
radars  have  degraded  performance  due  to  ECM  or  clutter, 
SEAFIRE  will  provide  independent  target  tracking  data.  The 
fire  control  operator  can  then  select  the  sensor  which  is 
providing  the  best  track  data. 

c.  In  the  event  of  a  detection/track  function  or 
equipment  failure  of  the  GFCS  sensor(s),  SEAFIRE  will 
provide  a  total  casualty  capability  for  the  GFCS, 
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allowing  continued  gun  and  gunfire  control  by  providing 
target  tracking  data.  This  will  be  accomplished  by  using  the 
GFCS  displays  and  controls,  where  practical,  and  the  GFCS 
computer  to  perform  the  gun  control  functions  such  as 
ballistics,  ammo  select,  fuze  function  and  code  set,  signal 
data  transmission  and  mount  status. 

d.  Under  EMCON,  the  SEAFIRE  passive  imaging 
sensors  nay  be  used  in  horizon  search,  or  to  evaluate 
contacts  detected  by  the  ship's  other  passive  sensors.  If 
tactics  permit  limited  emissions,  the  passive  imaging 
sensors  may  be  used  with  the  Laser  Rangef mder/Illuminator 
(LR/I )  transmitting  single  shot  to  generate  fire  control 
solutions  while  remaining  covert. 

e.  For  Laser  Guided  Ordnance  (LGO)  engagements 
SEAFIRE  will,  as  a  minimum,  provide  laser  target 
illumination  during  the  actual  guidance  time  of  the  LGO.  To 
minimize  operator  workload  during  this  critical  period  of  an 
engagement,  SEAFIRE  should  be  optimized  for  automatic  target 
tracking. 

C.  REQUEST  FOR  PROPOSAL 

As  previously  mentioned,  a  Reauest  for  Proposal  (RFP) 
was  released  to  industry  for  design  and  support  of  SEAFIRE. 
The  contractor's  response  required  not  only  a  firm  system 
design  but  also  ^ata  substantiating  his  awareness  of  and 
implementation   experience   in   production  and   life   cycle 
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support  of  major  weapons  systems.  The  following  is  a  list  of 
volumes  included  in  the  cortractor's  proposal: 

1.  Prime  Item  Development  Specification 

2.  Interface  Definitions 

3.  Master  Test  Plan 

4.  Substantiating  Technical  Data 

5.  System  Project  Management 

6.  Training 

7.  Support  and  Test  Equipment  Plan 

8.  Contractor  Furnished  Spares  and  Repair  Parts 

9.  Producibility  Engineering  and  Planning 

10.  Technical  Manual  Organizational  Plan 

11.  LAMPS  Electro-Optical  POD  Engineering  Considerations 

12.  Cost  Data 

The  above  list  depicts  the  depth  of  design/support 
detail  required  of  the  contractor  and  are  only  mentioned  to 
provide  a  top  level  view  of  the  information  used  by  the  U.S. 
Navy  evaluation  team. 

1 .  .Microprocessors/Firmware  Requirements 

The  SEAFIRE  computer  (see  Figure  1)  is  an  integral 
subsystem  which  provides  for  processing  of  all  data 
necessary  for  the  functioning  of  the  system.  The  word 
computer  is  a.  misleading  term  because  it  connotates  a  single 
item.   Although   the   SEAFIRE   contractor   was   provided   an 
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AN/UYK-20  computer  set  with  peripheral  equipment  for  use 
during  system  ievelopment  and  check-out,  in  actuality  he  was 
not  prohibited  from  using  additional  imbedded  processors  to 
support/enhance  the  AN/UYK-20  processing  capabilities. 
Specifically  the  use  of  microprocessors  was  encouraged. 

The  BFP  stated  that  microprocessors  introduced  in 
SEAFIRE  would  be  selected  based  on  performance, 
logistic/maintenance  support,  ease  of  programming  and  cost. 
Additionally,  microprocessor  architecture  would  have  to  be 
designed  to  emulate  a  subset  of  the  AN/UYK-20  computer 
instruction  repertoire  such  that  presently  available  Navy 
development  software  (e.g.  CMS-2  compiler,  assemble  debug 
tools,  data  retrieval,  data  reduction,  etc.)  could  be  used 
to  minimize  development/life  cycle  support  risk  and  cost.  At 
least  a  20  percent  memory  reserve  and  a  35  perqent 
processing  time  reserve  applies  to  each  processor.  In 
addition,  the  firmware  development/documentation/testing  and 
review  would  be  treated  the  same  as  the  software  development 
documentation/testing  phases.  Firmware  is  defined  as  all 
software  that  is  not  resident  in  the  AN/UYK-20  and  is 
necessary  for  the  operation  of  SEAFIKE.  This  includes  all 
programs  developed  for  microprocessors,  microcomputers,  and 
microcontrollers.  The  microprocessors  were  also  to  be 
designed  such  that  effort  required  to  change  the  program  for 
an  inservice  SEAFIRE  would  be  minimized. 

Based  on  the  above  description  in  the  RFP,  each 
contractor   team   responded   with   a   distincly   different 
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computer  architecture  for  SEAFIRE.  Due  to  this  fact  and 
others  as  stated  before,  the  evaluation  of  varying  computer 
architectures  on  the  same  strict  performance  factors 
presented  a  difficult  problem  and  did  not  necessarily  result 
in  the  ""best"  computer  architecture  selection.  Be  that  as  it 
may,  the  design  presented  in  the  next  section  is  the 
evaluation  object  for  this  thesis  and  it  is  hoped  that  as  a 
result  of  the  performance  evaluation,  specific  proposals  can 
be  suggested  which  may  provide  possible  system  enhancements. 

D.   PROPOSED  CONTRACTOR  SYSTEM  DESIGN 

1 .   System  description 

SEAEIRE,  as  described  by  the  system  contractor 
(21), is  an  Electro  -  Optical  Fire  Control  Subsystem  (EOECS) 
modular  addition  to  existing  shipboard  Gun  Fire  Control 
Systems  (G-FCS)  Mk  86,  Mk  6S ,  and  Mk  92.  This  addition  allows 
those  functions  previously  defired. 

The  modular  design  of  SEAFIRE  permits  it  to  be 
configured  as  an  independent  GFCS  for  application  onboard 
ships  on  which  there  is  no  other  GFCS.  (  See  Figure  2)  As  an 
independent  GFCS,  SEAFIRE  can  perform  the  functions  listed 
above  and  all  functions  neccessary  to  engage  and  direct 
gunfire  against  all  trackable  surface  targets,  including 
direct  acceptance  of  tactical  information,  interface  with 
own  ship  sensors,  generation  of  erun  laying  orders,  and 
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interface  with  gun  mounts. 

2.  General  Description 

SEAFIRE  comprises  two  primary  eauipment  groups, 
which  are  implemented  in  accordance  with  the  Standard 
Electronic  Module  (SEM)  program: 

a)  The  above  deck  equipment,  consisting  of  the  EO 
director.  The  EO  director  includes  an  enclosed  turret,  which 
is  mounted  on  the  outer  gimbals  of  the  SEAFIRE  pedestal.  The 
turret  enclosure  is  designed  to  house  the  Television  Sensor 
(TVS),  Thermal  Imaging  Sensor  (TIS)  and  Laser  Rangefinder/ 
Illuminator  (LR/I).  The  turret  is  temperature-controlled  to 
optimize  sensor  performance. 

b)  The  below  deck  eauipment,  consisting  of  the  Below 
Deck  Processor  (SDP),  Pedestal  Electronic  Cabinet  (PEC), 
Environmental  Control  System  (ECS),  Power  Converter  Unit 
(PCU)  ,  three  remote  video  displays,  and  a  console. 

A  common  SEAFIRE  interface  allows  integration  with 
host  or  independent  GFCS  without  hardware  or  software 
modifications.  The  console  for  the  independent  GFCS  includes 
the  processing  for  gun  order  generation  and  interface  with 
own  ship  systems.  This  impacts  only  the  external  interface 
to  the  applicable  ship  and  not  the  basic  SEAFIRE  interface 
design . 

System  processing  is  performed  in  the  AN/UYK-20 
computer   programmed  in  the  CMS-2  language.  Computer  program 
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components  are  required  to  implement  the  following 
functions:  Executive,  Input/Output,  Control,  Displays, 
Director  Control,  Target  Motion  Analysis,  Fault 
Isolation/Detection,  and  Data  Extraction.  The  program  is 
constructed  in  modules,  with  each  module  structured  to 
perform  one  of  the  processing  functions.  The  multitude  of 
functions  that  must  he  performed  within  the  system  are 
interfaced  and  monitored  for  correctness  "by  the  BDP 
Interface  Controller,  which  also  performs  the  core 
activities  associated  with  fault  detection  and  location. 

As  previously  mentioned,  the  contractors'  use  of 
microprocessors  was  encouraged  "by  the  U.S.  Navy.  The 
contractor  has  chosen  to  implement  microprocessor  technology 
in  the  BDP  unit.  Specifically,  microprocessors  or 
microcontrollers  are  implemented  in  the  following  units  of 
the  BDP: 

a)  Interface  Controller  (IPC) 

b)  Automatic  Video  Tracker  (AVT) 

c)  Data  Director  (DD) 

It  was  originally  intended  to  perform  the  analysis 
in  this  thesis  on  algorithms  running  on  the  microprocessor 
architecture.  But  since  much  of  the  architectures'  software 
and  hardware  is  still  in  the  process  of  design  and  the  fact 
that  several  areas  may  currently  he  proprietary  to  a 
contractor  or  suhcontractor ,  these  architectures  were  not 
evaluated.  The  particular  facet  of  the  system  evaluated 
(AN/UYK-20  Computer  Program  Components)  will  he  explained  in 
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a  later  section. 

3.  AN/UYK-20  Functional  Description 

This  section  provides  an  overview  of  the  software 
functional  Computer  Program  Configuration  Item  (C?CI)  and 
its  included  Computer  Program  Components  (CPCs).  The 
software  architecture  and  interface  are  also  described.  The 
SEAFIRE  computer  serves  as  the  controlling  center  of  the 
SEAFIRE  system,  receiving  data  from  its  separate  components, 
and  routing  information  to  those  components  reouiring  data 
from  other  sources  (see  figure  3  ). 

The  SEAFIRE  Interface  will  provide  the  SEAFIRE 
Computer  with  the  means  to  communicate  with  all  of  the 
SEAFIRE  hardware  components,  collecting  data  from  each 
component  and  transferring  these  data  to  the  SEAFIRE 
Computer  in  a  single  Mock.  Similarly,  the  SEAFIRE  Interface 
will  receive  outputs  from  the  SEAFIRE  Computer  and 
distribute  these  data  among  the  SEAFIRE  hardware  components. 
To  the  SEAFIRE  Computer,  all  of  the  SEAFIRE  hardware 
components  appear  to  he  a  single  device,  "because  a  single 
block  transfer  is  performed  for  both  input  and  output. 
Furthermore,  a  single  input  interrupt  and  single  output 
interrupt  is  involved.  Due  to  the  appearance  of  a  single 
input/output  device  relative  to  the  SEAFI?E  Computer,  the 
software  is  discussed  in  terms  of  the  SEAFIRE  Interface  (ie, 
same  as  Interface  Controller  or  Below  Deck  Processor). 
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The  host  GFCS  Operator  will  be  able  to  control  and 
monitor  the  SEAFIRE  System  at  the  Weapon  Control  Console 
(VCC).  The  WCC  is  upgraded  to  include  a  SEAFIRE  Control 
Panel  for  control,  and  a  shared  Video  Display  for 
monitoring.  The  Television  Sensor  (TVS)  or  Thermal  Imaging 
Sensor  (TIS),  used  with  the  AVT,  and  director  position 
readouts  will  provide  the  SEAFIRE  Computer  information 
neccessary  to  determine  target  azimuth  and  elevation.  The 
Laser  Rangef inder/Illuminator  (LR/I)  will  provide  the  range 
to  the  target.  Using  information  from  these  sources,  the 
SEAFIRE  Computer  will  be  capable  of  outputting  target 
position,  velocity,  and  acceleration  to  the  GFCS  for 
engaging  the  target.  The  optically  aligned  TVS,  TIS,  and 
LR/I  common  optical  pointing  will  be  controlled  by  a  single 
azimuth  and  elevation  rate  command  from  the  SEAFIRE  Computer 
(see  figure  4) . 

The  target  image  data  received  by  the  TVS  and  TIS 
will  be  sent  to  the  AVT,  where  the  target  position  is 
calculated.  The  AVT  will  determine  target  position  relative 
to  the  upper  left  corner  of  the  video  raster  and  send  the 
target  relative  position  data  to  the  SEAFIRE  Computer  at  a 
6?   Ez  rate. 

AVT  data  may  come  from  either  the  TVS  or  TIS,  bat 
not  simultaneously.  The  data  source  is  specified  by  the 
operator  at  the  SEAFIRE  Control  Panel.  Additional  options 
are  available  at  the  SEAFIRE  Control  Panel  that  affect  the 
data  flow  from  the  TVS/TIS  to  the  AVT  and  actual  processing 
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within  the  AVT,  embedded  microprocessor.  The  operator  may- 
select  one  of  up  to  six  filters  to  modify  the  video  input  at 
the  TVS/TIS.  For  the  TIS  only,  he  may  control  the  Gain, 
Bias,  and  select  either  Black  or  White  track.  lor  the 
TVS/TIS  he  may  control  video  Enhancement,  Focus,  and  select 
either  Wide  Field  Cf  View  (WFOV)  or  Narrow  Field  Of  View 
(NFOV).  At  the  AVT,  he  may  select  either  Scene  or  Point 
digital  tracking. 

The  SEAFIRE  Computer  will  pass  the  target  position 
through  a  Kalman  Filter?  (1)  to  smooth  the  target  position 
to  a  steady  state,  (2)  to  calculate  target  position, 
velocity,  and  acceleration  and  (3)  to  predict  where  the 
target  will  he  in  the  next  update  cycle.  The  SEAFIRE 
Computer  will  then  output  target  position,  velocity  and 
acceleration  via  NTDS  Slow  Interface,  to  the  GFCS,  so  that 
the  GFCS  can  compute  a  ballistic  solution.  The  data  input 
and  output  over  the  NTDS  Slow  Interface  will  he  identical 
for  the  four  configurations  cf  the  SEAFIRE  System  (Mk  86,  Mk 
68,  Mk  92  and  Standalone);  therefore,  only  one  version  of 
the  computer  program  need  he  maintained.  The  development  and 
maintenance  cf  only  one  computer  program  reduces  costs  and 
accents  software  commonality.  The  SEAFIRE  Computer  also  will 
output  commands  to  move  the  Director  so  that  the  target  will 
remain  in  the  TVS/TIS  FOV. 

The  SEAFIRE  Computer  contains  one  Computer  Program 
Configuration  Item  (CPCI);  the  Operational  CPCI.  The 
Operational   CPCI   is   used   as   a   G-FCS   to   provide  target 
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tracking  and  engagement  and  to  maintain  the  SEAEIRE  system 
in  a  state  of  operational  readiness.  The  Operational  CPCI 
performs  eight  major  functions: 

a)  Executive 

d)  Input/Output 

c)  Control 

d)  Display 

e)  Tracking 

f)  Director 

g)  Fault  Isolation/Detection 
h)  Data  Extraction 

The   CPCs   listed  below   perform   the   eight   major 
functions  of  the  Operational  CPCI: 


Executive 

SEAEIRE  Input  Interrupt 

SEAEIPE  Output  Interrupt 

NTDS  Slow  Input  Interrupt 

NTDS  Slow  Output  Interrupt 

NTDS  East  Input  Interrupt 

NTDS  East  Output  Interrupt 

Control  Panel  Input 

Control  Panel  Processor 

Director 

Designation 

Target  Motion  Analysis 

Alphanumeric  Display 

Symbology  Display 
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o)  Built  In  Test 

p)  Performance  Monitoring 

g  )  Data  Extracti  on 

r)  Clock  Synchronization 

The  functions  allocated  to  each  will  not  be  described 
in  detail.  The  data  flow  between  each  of  the  above  CPC 
functions  is  shown  in  Figure  5.  As  can  be  seen  Target  Motion 
Analysis  (TMA)  it  is  a  major  central  function  to  the  system 
as  it  includes  I/O  to  several  other  key  functions.  A 
description  of  the  TMA  is  delineated  in  the  next  section. 

4.  Target  Motior  Analysis  (TMA) 

The  TMA  CPC  is  called  by  the  Executive  CPC  at  a  4  Hz 
rate  to  compute  target  position,  speed,  and  acceleration  for 
output  to  the  GECS  and  to  the  Display  CPC.  Executive  rate 
will  be  4  Hz  since  GECS  outputs  are  required  at  this  rate. 
The  TMA  CPC  will  use  the  AVT  reported  target  position 
relative  to  the  raster  upper  left  corner  position,  Boresight 
Offset,  Sensor  Type,  and  Director  Azimuth  and  Elevation  to 
determine  the  target  position,  velocity,  and  acceleration. 

The  Director  will  provide  inputs  neccessary  to 
determine  Sensor  Line  Of  Sight  (LOS)  in  terms  of  azimuth  and 
elevation,  and  the  AVT  will  provide  inputs  such  that  target 
azimuth  and  elevation  relative  to  the  LOS  can  be  obtained. 
In  manual  track,  only  the  Director  angles  are  used.  The  LR/I 
will  provide  target  range  as  the  input. 
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The  AVT  will  report  the  target  azimuth  error  and 
elevation  error.  This  position  must  he  transformed  to  a 
position  relative  to  the  LOS,  and  must  he  adjusted  further 
for  the  effects  caused  hy  Control  Panel  selections.  Finally, 
the  position  in  elements  must  he  converted  to  units  in 
degrees.  Control  Panel  selections  have  the  effects  listed  as 
follows: 

a)  The  numher  of  degrees/element  is  different 
depending  on  wide  or  narrow  FOV  selection. 

b)  The  Boresight  offset  varies  as  a  function  of 
TVS  or  TIS  sensor  selection. 

c)  The  algorithm  can  he  changed,  and  therefore,  the 
target  position. 

The  TMA  CPC  will  include   the   necessary  processing 


to  : 


a)  Correct  for  angle  hias,  convert  target  data 
to  the  appropriate  reference  frame,  and  correct 
for  parallax, 
h)  Prefilter  the  data  to  correct  for  timing  delays. 

c)  Perform  TMA  computations  reauired  to  derive 
smooth  target  state  variables  (position,  velocity, 
acceleration)  in  hoth  the  stabilized  Spherical 
and  Cartesian  coordinate  frames. 

d)  Perform  necessary  computations  during  coast 
conditions. 

e)  Output  track  quality  data. 

At   the  end  of  the  Kalman  filter,  maneuver  detection 
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is  performed.  The  maneuver  detection  subroutine  is   part   of 
the  TMA  CPC  hut  is  not  discussed  due  to  its  classification. 

E.  SUMMARY 

Now  that  the  system  has  been  described  and  methodologies 
have  been  discussed  in  general  for  performance  evaluation  of 
computer  systems,  the  next  logical  step  is  a  specific 
application  of  one  of  these  techniques.  The  next  section 
provides  a  description  of  the  performance  tool  that  is  to  be 
applied  in  the  evaluation  of  the  SEAEIRE  system. 
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V.   USE  OF  AN  EXISTING  COMPUTER  SYSTEM  PERFORMANCE  TOOL 
A.  INTRODUCTION 

The  methodology  to  he  used  for  the  computer  performance 
evaluation  is  the  one  designed  by  L.  A.  Cox,  Jr.  (-i).  This 
section  provides  a  summary  of  his  approach. 

In  his  dissertation,  Cox  described  the  develoument  of  a 
methodology  for  efficiently  predicting  concurrent  computer 
system  performance.  This  methodology  allows  the  estimation 
of  performance  of  an  existing  (or  conceptual)  computer 
organization  operating  on  a  linear  mathematical  algorithm. 
An  existing  program  is  taken  and  the  control  structure  of 
all  or  some  representative  kernel  of  the  code  is  expressed 
in  a  fashion  which  makes  the  potential  parallelism 
exploitable.  For  a  given  computer  system,  the  control 
structure  dictated  by  the  software  can  then  be  mapped  onto 
the  hardware  structure,  and  the  performance  predicted. 

The  key  to  this  process  is  the  representation  of  a 
kernel  program  or  one  of  the  basic  cyclic  events  as  a 
special  kind  of  Petri  Net  simular  to  a  marked,  directed 
graph.  In  the  directed  graph,  each  arc  can  be  regarded  as 
having  some  propagation  delay  which  is  dependent  upon  the 
performance  of  the  computer  system  executing  the  program.  If 
these  delays  are  fixed  and  known,  then  the  question  of 
performance  reduces  to  a  question  about  the  minimum  period 
for  the  cyclic  behavior  of  the  marked  graph  which  represents 
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the  program. 

A  requester/server  interface  provides  for  construction 
of  a  two  graph  structure  which  allows  the  representation  of 
algorithms  and  hardware  organizations  by  separate  graph 
structures.  This  permits  each  graph  to  he  constructed  in 
such  a  manner  as  to  hoth  express  the  control  structure  and 
to  maintain  a  direct  and  meaningful  representation  of  the 
important  concepts  being  modeled. 

B.  DEVELOPMENT  OE  THE  DESIGN  EVALUATION  SYSTEM 

An  effective  concurrent  computer  system  design  tool  must 
consider  the  characteristics  of  both  systems  and  software  on 
a  more  conceptual  level.  Hopefully,  the  same  descriptive 
system  could  be  employed  to  describe  both  the  hardware 
organization  and  the  software  requirements.  The  design 
evaluation  system  should  provide  for  the  inclusion  of 
varying  levels  of  detail  in  some  hierarchical  manner  and 
should  provide  quantitative  results  of  concurrent  systems  in 
some  cost  effective  manner. 

Why  use  Petri-Nets  for  the  predictive  system?  A 
Petri-Net  may  be  thought  of  as  an  abstract,  formal  model  of 
information  flow.  As  such,  it  is  possible  to  describe  not 
only  the  information  flow,  but  the  controls  and  constraints 
of  such  flow.  The  Petri-Net  graph  models  the  static 
structure  of  a  system  in  much  the  same  manner  as  a  flowchart 
models  the  structure  of  a   computer   program.   In   order   to 
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represent  the  dynamic  properties  of  the  system  to  be 
modeled,  a  Petri-Net  can  be  "executed"  to  respond  to  the 
flow  of  information  (or  the  occurrence  of  events)  in  the 
system. 

The  static  graph  of  a  Petri-Net  is  composed  of  two  types 
of  nodes,  circles  which  are  traditionally  called  places,  and 
bars  which  are  called  transitions.  These  nodes  are  connected 
by  directed  arcs  which  run  from  either  places  to  transitions 
or  from  transitions  to  places.  The  source  of  a  directed  arc 
is  referred  to  as  the  input,  while  the  terminal  node  is 
referred  to  as  the  output . 

The  dynamic  execution  of  a  Petri-Net  is  controlled  by 
the  position  and  movement  of  information,  as  represented  by 
markers  which  are  called  tokens.  Movement  of  the  tokens 
proceeds  according  to  certain  rules.  A  token  or  tokens  move 
when  a  transition  fires.  In  order  to  fire,  a  transition  must 
be  enabled,  that  is  all  of  the  places  which  are  inputs  to 
the  transition  may  fire.  When  a  transition  fires,  the  tokens 
are  removed  from  the  input  places,  and  tokens  are  placed  on 
all  output  places  of  the  transition. 

Petri-Nets  can  model  actual  parallel  processes  by 
attaching  some  significance  to  token  movement.  For  example, 
multiple  outputs  from  a  transition  create  multiple  tokens 
upon  firing,  which  could  be  interpreted  as  a  "fork" 
operation  activating  multiple  parallel  processes.  Similarly, 
the  multiple  inputs  to  a  transition  (which  must  all  be 
marked  for  the  transition  to  fire)  could  be  interpreted  as  a 
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'join'  operation  terminating  or  merging  independent  parallel 
sequences . 

In  each  case,  the  status  of  the  execution  at  a  given 
time  can  "be  described  by  defining  the  status  of  the  tokens. 
This  distribution  of  tokens  in  a  marked  Petri-Net  is  called 
the  marking,  and  defines  the  state  of  the  net  for  a  given 
instant.  Figures  6  through  9  show  the  different  stages  of  a 
marked  Petri  Net  progressively  at  incremental  time  units  in 
the  system. 

As  first  formally  defined  by  Petri,  Petri-Nets  were  not 
always  deterministic.  For  the  purposes  of  performance 
evaluation,  a  small  restriction  was  made  to  eliminate 
non-determinism,  something  not  generally  sought  after  in 
either  hardware  or  software. 

Petri-Net  concurrent  control  system  models  have  many 
characteristics  which  are  desirable  in  a  concurrent  computer 
system  performance  prediction  system.  This  model  is  capable 
of  representing  both  hardware  and  software  systems  and  is 
hierarchical  in  nature.  These  characteristics  are  important 
in  the  predictive  system. 

C.  THE  PETRI  PERFORMANCE  PREDICTIVE  PACKAGE  (P4) 

The  requirement  for  an  architectural  design  aid  existed. 
Cox  created  and  implemented  on  an  experimental  basis,  a 
performance  prediction  system  based  on  Petri-Net  models.  The 
system,  named  P4 ,  standing  for  Petri  Performance  Predictive 
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Package,  is  described  below.  Major  components  of  the  P4 
system,  and  the  system's  intended  employment  are  shown 
graphically  in  figure  10.  The  model  implemented  at  NFS  does 
not  utilize  the  MAC  macro  expander  or  the  macro  library. 

The  design  of  a  new  computer  system  (or  the  modification 
of  an  existing  system)  is  usually  initiated  with  the 
realization  that  a  problem  exists  whose  solution  is  both 
important,  and  not  economically  feasible  in  some  sense.  The 
P4  system  is  intended  to  be  used  in  cases  where  a  problem 
has  been  defined  and  a  system  architecture  is  to  be 
developed.  In  response  to  this  problem,  the  designer 
develops  a  solution  concept.  This  concept  includes  the 
algorithmic  portion  of  the  problem,  and  some  computer 
organization  which  hopefully  will  solve  the  problem  within 
the  various  constraints. 

At  this  poirt  the  designer  describes  this  solution 
concept  in  terms  of  the  P4  system.  A  P4  program  (P5) 
consists  of  a  discription  of  the  computer  system 
organization  and  capabilities.  As  we  will  see  later,  these 
descriptions  are  Petri-Nets,  and  in  order  to  make  use  of  the 
heirarchical  nature  of  these  nets,  and  to  express  system 
organizations  in  a  more  concise  and  convenient  manner,  a 
macroprocessor  was  included  in  the  system;  although  one  is 
not  used  in  this  thesis.  A  P4  program  can  be  either  a  "pure" 
P5  description,  or  can  make  use  of  the  macro  facility,  in 
which  case  it  is  referred  to  as  a  P5M  description.  This 
description  of  the  solution  concept  is  then 
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evaluated  in  a  dynamic  sense  and  produces  an  analysis  of  the 
system's  predicted  performance. 

The  performance  predictions  are  made  on  the  basis  of  the 
execution  of  a  Petri-Net  simulator.  This  simulator  operates 
on  the  P5  description  of  the  proposed  system.  A  complete  P4 
program  which  is  to  be  evaluated  by  the  Petri-Net  simulator 
consists  of  three  sections:  a  hardware  section,  a  software 
section  and  a  dynamic  section.  The  hardware  section  consists 
of  a  description  of  the  basic  subsystems  of  the  computer 
system  and  some  degree  of  subsystem  interconnections.  The 
network  which  represents  hardware  is  auantified  in  terms  of 
its  operation  in  time.  The  software  section  consists  of  a 
description  of  a  Petri-Net  which  represents  the  algorithm  to 
be  executed  on  the  system.  This  net  is  quantified  in  terms 
of  the  basic  functions  which  are  to  be  required  of  the 
hardware.  The  dynamic  section  contains  certain  output 
instructions  and  specifications  of  the  Petri-Net's  initial 
conditions.  Formally,  both  the  software  section  and  the 
hardware  section  are  merely  descriptions  of  static  Petri-Net 
structures.  Performance  prediction  comes  from  the  attachment 
of  certain  significance  to  the  structures  and  certain 
restrictions  on  the  movement  of  tokens  or  markers  within 
these  networks. 

The  dynamic  nature  of  Petri-nets  is  used  to  approximate 
the  actitively  of  the  proposed  computer  system  as  it 
executes  the  algorithm  of  interest.  Accordingly,  the  two 
Petri-Nets,   software   and   hardware,   can   be   viewed   in  a 
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requester/server  context.  The  software  or  algorithm  makes  a 
series  of  requests  for  the  services  of  the  computer  system. 
The  computer  system  fulfills  these  requests  according  to  the 
constraints  of  its  design. 

In  the  hardware  net,  events  roughly  represent  operations 
in  time.  A  collection  of  one  or  more  events  are  used  to 
represent  a  functional  unit  and  its  temporal  response  to  the 
hardware  control  constraints.  Token  movement  through  the 
hardware  net  represents  the  data  and  control  flow  of  the 
hardware  system.  A  simple  example  of  a  ?5  hardware 
description  is  shown  in  figure  11. 

The  software  net's  events  represent  "basic  requests  for 
service.  For  example,  an  event  might  represent  a  request  for 
an  integer  addition.  The  flow  of  tokens,  which  is  initiated 
by  a  single  marker  on  the  event  "BEGIM",  represents  the 
logical  flow  of  the  algorithm.  An  example  of  the  hardware 
and  software  net  is  shown  in  figure  12. 

Once  these  two  Petri-Net  structures  have  been  defined, 
they  can  he  executed  together  in  a  manner  which  will 
simulate  the  operation  of  the  computer  system.  The 
interaction  of  the  two  nets  is  controlled  "by  the 
'requester/server  token  arbiter.'  The  network  simulation 
begins  with  the  marking  of  the  "3EGIN"  node  of  the  software 
net.  This  net  is  then  executed  according  to  standard  Petri 
rules.  The  arrival  of  a  token  at  a  place  in  the  net  is 
interpreted  as  a  request  fqr  service,  the  type  of  service 
depending  on  the  type  of  the  place.  Upon  arrival,  the 
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arbiter  is  notified  of  the  request  for  service. 

The  arbiter  removes  the  token  from  the  net,  and  allows 
the  software  net  execution  to  continue  until  such  time  as  no 
further  moves  are  possible.  At  this  time,  the  arbiter 
initializes  the  appropriate, hardware  units  which  correspond 
to  the  requests  by  marking  them  with  tokens. 

The  hardware  net  is  then  executed  one  step.  If  any 
tokens  reach  events  which  correspond  to  completion  of 
requested  service,  the  arbiter  is  notified.  Here  again,  the 
token  is  removed,  and  the  token  of  the  software  net  whose 
movement  caused  the  original  request  for  service  is  replaced 
by  the  arbiter.  This  cycle  is  repeated,  with  the  execution 
of  the  software  network,  followed  by  execution  of  the 
hardware  network.  A  P5  dynamic  section  and  the  P4  results  of 
the  examples  shown  in  figures  11  and  12  are  shown  in  figure 
13. 

Examples  were  tried  by  Cox  and  predicted  results  agreed 
well  with  actual  measurements  in  most  cases.  Some  cases  with 
wide  discrepancies  pointed  out  a  significant  characteristic 
of  the  P4  methodology.  When  maximally  parallel 
representations  of  the  hardware  and  the  software  are 
provided  to  P4,  the  resulting  prediction  in  most 
circumstances  represents  the  "best  case"  execution  time. 
This  means  that  in  cases  where  a  system  has  been  either 
implemented  or  simulated  at  the  bit  level,  P4  predictions 
can  be  compared  with  bit  level  timings  and  used  as  an 
indication  of  the  efficiency  of  the  assembly  code  generated 
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by  either  manual  or  automated  means. 

The  results  Cox  received  indicated  that  the  P4 
methodology  provides  not  only  a  simple  and  accurate  method 
for  predicting  computer  system  response  "but  is  economical  of 
modeling  resources  as  well. 

D.  LIMITATIONS  OF  THIS  APPROACH 

The  Petri-Net  is  a  concurrent  control  system  model  of 
demonstrated  power?  however,  Cox  indicated  that  it  does  have 
some  limitations,  perhaps  the  most  significant  of  which  is 
its  inability  to  represent  conditional  events.  Petri-Nets 
are  not  able  to  handle  these  conditions  as  they  are 
traditionally  designed.  Some  work  has  been  done  on 
developing  extensions  to  Petri  representations  which 
consider  this  situation  though  a  model  which  basically 
represents  data  as  tokens  is  difficult  to  extend  to  data 
value  dependent  situations. 

Cox  indicated  that  these  extensive  modifications  do  not 
appear  to  be  justified  in  view  of  the  intended  operation  of 
the  performance  model.  In  general,  the  linear  mathematical 
models  which  drove  his  research  can  be  characterized  by  a 
single  or  at  most  a  few  main  computational  loops.  The 
performance  of  the  loop  calculation  drives  the  overall 
performance  of  the  program.  These  loops  can  be  represented 
as  linear  code,  and  their  performance  evaluated.  Using  this 
methodology,  the  conditional  path  problem  is  avoided. 
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Another  limitation  of  the  P4  approach  stems  not  so  much 
from  the  concept,  hut  from'the  realization.  Both  software 
and  hardware  must  he  described  in  terms  of  descriptions  of 
Petri-Nets.  These  descriptions  are  "programs"  which  are 
subject  to  all  of  the  problems  of  any  human  generated 
program. 

Experience  has  shown  that  the  representation  of  existing 
computer  programs  and  algorithms  as  Petri-Nets  is  usually 
straightforward.  Few  errors  have  occurred  at  this  stage.  The 
automatic  generation  of  these  descriptions  from  a  FORTRAN  or 
other  algorithmic  language  source  may  be  possible. 

The  representation  of  hardware  structures  has  proven  a 
bit  more  complex.  The  hardware  Petri-Net  program  must 
carefully  include  all  explicit  and  implicit  limitations  to 
concurrency  which  the  system  will  impose.  This  requires 
careful  consideration  of  each  design,  and  careful 
programming,  sometimes  by  persons  without  significant 
programming  experience.  In  hardware  systems  which  make  use 
of  variable  time  intervals  for  execution  (such  as  the  data 
dependent  nature  of  completion  signaling  devices),  some 
average  propagation  delay  must  be  substituted.  This 
complicates  somewhat  the  programming  problem  by  demanding  a 
detailed  analysis  of  some  sub-systems,  and  by  including 
"average  performance"  figures. 

There  is  one  other  property  which  should  be  mentioned. 
Currently,  there  is  considerable  discussion  of  "data  flow" 
computer  architectures.  These  are  machines   which   would   be 
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based  on  the  principle  of  executing  instructions  in  response 
to  the  arrival  of  operands  rather  than  in  response  to  some 
sequential  or  explicit  control  flow.  These  machines  are 
conceptually  important  because  programs  expressed  in  data 
flow  form  are  free  from  sequencing  constraints  other  than 
those  required  by  the  algorithm,  and  a  processor  using  data 
flow  representation  can  achieve  highly  parallel  operation. 
In  the  Petri  performance  model,  all  programs  are  expressed 
in  essentially  a  data  flow  notation.  A  Petri  performance 
prediction  as  previously  described  makes  use  of  all  the 
possible  parallelism  of  both  the  hardware  and  software,  and 
is  thus  "best  case"  in  some  sense. 

This  "best  case"  prediction  property  stems  from  the  fact 
that  when  properly  represented  in  Petri-Net  structures  the 
hardware  and  software  descriptions  describe  potential 
parallelism  on  a  global  basis.  The  mapping  of  requests  for 
service  into  actual  hardware  operations  makes  use  of  this 
global  parallelism,  and  the  limits  are  only  those  explicit 
in  either  the  hardware  or  software.  It  is  this  property  of 
the  Petri  performance  model  that  makes  it  useful  in  the 
evaluation  of  the  efficiency  of  generated  code,  and  makes  it 
a  valuable  tool  in  investigations  of  compiler  and  language 
development  for  highly  parallel  machines. 

Cox's  initial  experience  using  the  P4  methodology  has 
shown  that  performance  predictions  based  on  dual  Petri-Net 
representations  of  hardware  and  software  structures  are 
accurate  and  efficient  in  terms   of   resources   required   to 
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make  the  predictions.  Additionally,  the  system  is  easy  and 
sufficiently  general  so  as  to  permit  detailed  investigations 
of  alternative  computer  system  organizations  such  as  would 
be  expected  in  the  design  and  development  of  a  new  system 
such  as  SEAFIRE. 

E.  SUMMARY 

The  Petri  performance  model  has  some  limitations  which 
must  he  understood  before  it  can  be  properly  applied; 
however,  when  intelligently  used,  it  comes  very  close  to 
fulfilling  all  the  goals  of  an  ideal  design  tool  intended 
for  use  in  the  conceptual  development  of  concurrent  computer 
system  organizations.  The  next  section  deals  with  the  actual 
implementation  of  the  technique  described  in  this  chapter. 
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VI.       IMPLEMENTATION /EXPERIMENTAL    PROCEDURES 

A.  INTRODUCTION 

This  section  provides  a  description  of  the  hardware  and 
software  model  for  SEAFIRE  and  how  this  model  was  executed 
by  the  Petri-Net  simulator.  Some  of  the  detail  that  was 
required  concerning  the  actual  functioning  of  the  SEAFIRE 
software  was  not  available  and  therefore  certain  assumptions 
had  to  be  made  in  order  to  develop  these  netsworks.  The 
results  of  the  analysis  is  covered  as  a  function  of  the 
number  of  target  loops  (TMA)  generated. 

B.  A  DESCRIPTION  OF  THE  PROGRAM 

A  discussion  of  Computer  Software  Data  Flow  at  the  CPC 
level  was  provided  in  Chapter  IV  along  with  a  diagram  of  how 
the  CPCs  interface  (Figure  5).  Since  it  was  decided  to 
perform  the  analysis  at  the  CPC  module  level,  a 
representation  of  the  hardware  function  for  each  module  is 
best  represented  as  a  time  interval  delay  as  predicted  by 
the  contractor.  Table  1  depicts  the  contractor's  timing 
estimates  for  each  module  in  the  Automatic  Track  Mode.  These 
figures  have  been  rounded  off  for  ease  of  implementation. 

Figure  14  represents  the  SEAFIRE  hardware  (Machine  Net). 
Each  execution  cycle  (Dl, D3, . . . .D260)  is  utilized  for  one  or 
more  of  the  CPCs  of  Table  1.  The  interrupt  cycle   represents 
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the  first  seven  CPCs  listed.  These  interrupts  occur  at  a 
rate  of  645  per  second;  and  since  one  cycle  eauates  to  100 
usee,  one  interrupt  would  occur  approximately  every  15.5 
cycles.  The  other  calculations  are  linear  representations  of 
the  execution  time  for  each  CPC. 

Figure  15  depicts  the  test  estimate  of  how  the  software 
functions  for  SEAPIRE  in  the  Automatic  Track  Mode.  Steady 
state  was  assumed  so  that  the  designation  function  could  he 
ignored.  TMA  was  first  executed  for  a  total  of  two  target 
loops,  then  was  varied  on  additional  runs.  The  intention  was 
to  determine  the  loading  capacity  for  the  S5AFIRE  computer 
at  these  varying  stages  of  number  of  target  loops.  The  other 
routines  are  interrupt  driven  from  a  clock  and  are  depicted 
in  the  overhead  loop. 

As  previously  mentioned,  the  basic  simulator  was 
available  in  a  form  which  ran  on  a  CDC-5700  computer.  A 
large  amount  of  effort  to  modify  this  simulator  resulted  in 
the  program  of  APPENDIX  A  that  now  runs  on  a  PDP-11/50 
minicomputer  at  NPS.  Computer  printouts  of  the  resultant 
output  is  not  provided  as  it  was  felt  that  it  would  not  have 
been  of  significant  benefit  to  the  reader.  The  results  of 
the  analysis  are  discussed  in  the  next  section. 
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Computer  Program 
Components 

Executive 

SEAFIRE  Input  Interrupt 

SEAFIRE  Output  Interrupt 

NTDS  Slow  Input  Interrupt 

NTDS  Slow  Output  Interrupt 

NTDS  Fast  Input  Interrupt 

NTDS  Fast  Output  Interrupt 

Control  Panel  Input 

Control  Panel  Processor 

Director 

Designation 

Target  Motion  Analysis 

Alphanumeric  Display 

Symhology  Display 

3uilt-in  Test 

Continuous  Monitoring 

Data  Extraction 

Clock  Synchronizer 


Time  Per 

Execution(100us) 

Rate(Hz) 

490 

60 

60 

16 

16 

1 

1 

4 

60 

6 

10 

6 

60 

70 

16 

260 

4 

12 

60 

20 

20 

3 

60 

120 

1 

3 

60 

1 

1 

SEAFIRE  COMPUTER  TIMING  ESTIMATE 
FOR  AUTOMATIC  TRACK  MODE 

TABLE  1 
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GATE 


260 


OUTLINE  OF  SEAFIRE  HARDWARE  REPRESENTATION 

Figure  14 
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C.  PRESENTATION  OF  RESULTS 

Initial  results  showed  that  the  performance  of  the 
SEAFIRE  system  under  development  was  approximately  30%  below 
design  goals.  Detailed  analysis  of  the  performance 
prediction  showed  significant  problems  in  the  methodology 
used  to  predict  the  performance.  The  multiple  cyclic  loon 
structures  that  are  present  in  the  SEAFIRE  hardware/software 
representation  present  deadlock  like  competition  for  the 
hardware  resources.  Several  times  during  processing  it  was 
evident  that  one  cyclic  loop  would  gain  "control"  of  the 
hardware  to  the  exclusion  of  all  other  processes;  this  loop 
consuming  all  hardware  resources  available.  In  a  real  time 
system,  an  Executive  routine  would  drive  the  interrupts 
based  on  a  clock.  This  reflects  a  problem  of  using  the  P4 
system  as  it  currently  stands  to  model  real-time  (interrupt 
driven)  systems. 

Subseauent  experiments  indicated  that  the  computer 
program  flow  could  be  manipulated  in  a  cyclic  (synchronous) 
manner  to  approximate  an  interrupt  driven  environment. 
Although  the  results  closely  replicate  the  contractor's 
predictions  concerning  the  timing  estimates  required  for 
program  execution,  a  true  representation  of  the  real  time 
fire  control  program  was  not  created. 

It  would  also  have  been  preferred  if  the  processing  of 
the  embedded  microprocessors  could  have  been  included; 
although  it  would  have  been  rather  simple   to   implement   at 
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this  level,  the  results  would  net  have  teen  significantly 
altered.  A  lower  level  of  detail  (  ie,  software  running  on 
the  actual  hardware  )  would  provide  the  expected  output  of  a 
faster,  more  efficient  fire  control  solution  which  is  less 
dependent  on  the  centralized  processor  concept. 

The  final  timing  estimates  indicate  that  the  proposed 
software  design  will  meet  the  Navy's  processing  time 
requirements  and  have  the  capacity  of  expansion  to  include 
additional  functions  as  system  development  proceeds. 

After  further  analysis,  the  structure  of  the  programs 
were  modified  so  that  a  maximum  number  of  target  loops  could 
he  accomplished  without  consideration  for  the  administrative 
functions  . 
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VII .   CONCLUSIONS  AND  RECOMMENDATIONS 

The  U.S. Navy  and  DOD  are  not  doing  an  adequate  job  of 
specifying  and  developing  the  criteria  to  he  used  as 
standards  for  computer  system  evaluation  and  the  prediction 
of  their  performance.  The  tools  are  available,  but  yet  past 
methods  are  implemented  without  considering  innovative 
industrial  ideas.  Only  token  amounts  of  funding  are  expended 
where  the  payoff  is  the  greatest;  in  early  conceptual 
development  phases. 

Despite  the  advances  in  these  areas,  the  question  also 
arises  as  to  whether  the  DOD  can  exploit  these  ideas  with 
the  support  of  industry.  A  number  of  approaches  have  been 
actively  pursued  over  the  last  few  years,  however,  there  is 
not  currently  a  firm  direction  in  employing  these  new 
techniques  in  industry  or  DOD. 

A  new  dimension  for  the  analysis  of  computer 
architectures  has  emerged.  These  methods  can  enhance  the 
performance  of  computer  systems  and  create  an  iterative 
atmoshere  between  industry  and  DOD  which  is  required  for 
future  systems  development. 

The  methodology  presented  in  this  thesis  should  be 
considered  as  a  partial  effort  in  this  direction.  The 
approach  is  theoretically  sound  but  its  implementation 
requires  a  more  thorough  analysis  with  appropriate  tailoring 
for  its  implementation.  The  rapid  development  of  computer 
technology  dictates  that  the  DOD  be  able  to  better  cope  with 
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this  pace.  Further  research  and  development  into  the  causes 
and  the  nature  of  the  problem  of  simulating  an  interrupt 
driven  real-time  combat  system  is  highly  recommended. 
Section  V  mentioned  that  the  P4  system  is  directly  analogous 
to  data  flow  computing  models.  If  the  problem  is  inherent  in 
the  P4  system,  it  may  very  well  he  inherent  in  data  flow 
computing  models,  which  will  inhibit  their  use  in  this  type 
of  analysis.  For  this  reason,  it  makes  further  research  in 
this  area  imperative  prior  to  other  implementations.  It  is 
recommended  that  this  and  other  methodologies  be  explored 
further  and  hopefully  utilized  in  the  near  future. 
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APPENDIX  A 
PROGRAM  LISTING 

petrinet.ftn     Paae  1     Tue  Nov  27  06:18:55  1979 

1  C 

2  C 

3  C  PROGRAM  PETRI-NET  REQUESTOR/SERVER  SIMULATOR 

4  C 

5  C 

6  C 

7  C  THIS  PROGRAM  is  THE  REQUESTOR/SERVER  INTERFACE 

8  C  MODFL  FOR  IMPLEMENTATION  IN  THE  F5  NETWORK. 

9  C 

10  C 

11  COMMON/NET/  NET(255,4),NTRNS(255,3)rNFRE(999,2), 

12  1NXTF,KTIM£,NEV, NTR 

13  COMMON/SOFT/  JNfcT(255,4),JTRNS(255,3),JEV,JTR 

14  C 

15  DO  000^  T=l ,255 

16  NET(I,1)=0 

17  NTRNS(T,1)=0 

18  JNET(I,1)=0 

19  jrPNS(T,l)=0 

20  0005  CONTINUE 

21  CALL  IMIT 

22  C 

23  0010  CONTINUE 

2a  CALL  SCANRT5) 

25  IF(MATCHS(1 ,5HBEGIN,5) .EQ.l)  GO  TO  0020 

26  IFfMATCHSCt ,3HEND,3) .EQ.l )  GO  TO  OOaO 

27  CALL  ERRRRR(1,7H    MAIM, 0,0) 
2«  GO  TO  00/40 

29  C 

30  0020  CONTINUE 

31  IF(MATCHS(?,7HMACHINE,7).E0.1)  CALL  STATIC(NET, 

32  INTRNS,NEV,NTR) 

33  IFCMATCHS(?,7HDYNAMIC,7).EQ.n  CALL  DYNAMO 

34  IF(MATCHS(2,7HPR0GRAM,7).EQ.l)  CALL  PGMNET 

35  IF(MATCHS(l,3HEND,3).EQ.l)  GO  TO  0010 

36  IF(MATCHSC1,7HMACHINE,7).NE,1  .AND.  MATCHSU, 

37  17HDYNAMIC,7).NE.1 

38  1  .AND.  MATCHSCt , 7HPROGRAM, 7) .NE. 1 )  GO  TO  0030 

39  GO  TO  0010 
ao  C 

41  0030  CONTINUE 

42  CALL  ERRRRRC1,7H    MAIM, 0,0) 

43  C 

44  0040  CONTINUE 

45  CALL  DUMP(NET,NTRNS,NFRE,NXTF,KTIME,NEV,NTR) 

46  CALL  DUMP(JNET,JTRNS,NFRE,NXTF,KTIME,JEV,JTR) 

47  CALL  TDUMP 

48  CALL  EXIT 
4Q  END 

50  C 

51  C 

52  SUBROUTINE  IMIT 

53  COMMON/NET/  NET ( 255 , 4 ) , NTRNS f 255 , 3 ) , MFRE ( 999 , 2 ) , 

54  1NXTF,KT1ME,NEV,NTR 

55  COMMON/CTRLR/  TMODE , ICQ (250) 

56  COMMON/RAND/  RANDP 

57  C 

58  C       3TAPT-UP DEFINE  DEVICES  FOR  OUTPUT, 

5P  C  GET  START-UP  CTPLP  MODE  AND  RANDOM  MODE  PROBABILITY 

60  C  FROM  TTY.  CREATE  A  FICTICIOUS  NODE  'RANDOM'. 
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Petri  net. ftn 


Page  2 


Tue  Nov  27  06: 18:55  1979 


61 
6? 
63 
b« 
65 
66 
67 
68 
69 
70 
71 
72 
73 

7a 

75 
76 
77 
7P 
79 
80 
81 
8? 
83 
84 
85 
86 
87 
88 
89 
90 
91 
9? 
93 

9a 

95 

96 

97 

98 

99 

100 

101 

102 

103 

ioa 

105 
106 
107 
108 
109 
I  10 
1  11 
11? 
113 

l  ia 

115 
1  16 
1  17 
118 
1  19 
120 


0100 
0120 


opfn 

OPFiM 
1PEAD 
FORK' 
WRI  r 
FOP?-! 
'  RA 
CALL 
CALL 
CALL 
hKlT 
CPE 
CALL 
PETU 
FND 


(UNIT 

(UNIT 

ONLY) 

AT  f  /, 

EC7,0 

AT  C5X 

ND.  P 

SCAN 

XI  NT 

XFLQ 

E(7,0 

ATE  T 

NAME 

RN 


=7,NAME='NET0UI  .LST ' 
=5,NAM£='DP0:NETINP. 


,TYPE='NEW  ) 

INP; 1 ' ,TYPE='OLD' , 


VFR.  24',//) 


START-UP  MODE= 


1      NET -SIM 

100) 

,  '  *PROGRAM 

ROB.=  ',F6.?,//) 

Kf5) 

GR(1  , I  MODE) 

AT (?, RANOP) 

120)  TMODE,RAMDP 

HF  PHONY  NODE... AS  NUMBER 

IT (NET (255, 1 ),6HRAND0M,6) 


15, 


255 


SUBROUTINE  STATIC (KNET ,KTRNS, KEV ,KTR) 

CO^MON/D^'P/  NFREFl 
COMMON /SCAN/  NUMB, IW0RD(15,10) 

COMMON/NET. /  NET(255,a),NTRNS(255,3) ,NF RE (999,2) 
iMXTF,KTIME,NEV,NTR 


0200 


DIMENSION 

PrTE  TEMP 
DIMENSION 

n  e  r 

NFF (N, 1 ) 
NET (N,2) 
NET(N,3) 

NET  (N,4) 


KNET(255,a),KTRNS(255,3) 

TE^'Pf  10) 

DEFINITIONS 

POINTER  TO  NAMES  ARRAY  WHICH  HOLDS  NAME 
MARKER  (0  — )  UNMARKED) 
PESOURCE  REQUIREMENTS   (TYPE) 
OUTPUT  FLAG  FOR  EXECUTION  PRINT. 


NEV  IS  NUMBER  OF  EVENIS 


N  T  R  N  S 

N  T  R  N  S ( N ,  1) 

NTRNSf N,2) 

NTRNSfN, 3) 


DEFINITIONS 

=  NAME  OF  TRANSITION 

=  POINTER  TO  TRANSITION  INPUTS  IN  FREE 

SPACE 

=  POINTER  TO  TRANSITION  OUTPUTS 


NTR  IS  NUMBER  OF  TRANSITIONS 


N  F  R  E  E     DEFINITIONS 

NFRE(N,1)  POINTER  TO  AN  EVENT  IN  NET 
NFRE(N,2)  POINTFtf  TO  NEXT  ENTRY  IN  NFRE  OR  NIL 
NXTF  IS  POINTER  TO  NEXT  FREE  SPACE 

BEGIN  STA1IC  LOOP  TARLE  BUILDING 
CONTINUE 
CALL  SCAMRC5) 

IF (MATCHS( 1 ,3HEND,3) .EO. 1 )  GO  TO  0291 
IF(MATCHS(l,7HDECLARE,7).NE.l )  GO  TO  0290 
IF (MATCHS(3,5HEVENT,5) .EO. 1 )  GO  TO  0210 
IF(MATCHS(3, 1 OHTPANSI T ION, 10) .EQ. 1 )  GO  TO  02ao 

go  ro  o2^o 


(0) 
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121 
12? 
123 
124 
125 
126 
127 
128 
129 
130 
131 
13? 
133 
134 
135 
136 
137 
138 

139 
140 
141 

la? 
143 
144 

145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 

157 

158 

159 

160 

161 

16? 

163 

164 

165 

166 

167 

168 

169 

170 

171 

17? 

173 

174 

175 

1  76 

177 

178 

1  7« 

180 


0210 


Q2Z" 

0?30 
0  ?  4  0 

0250 


02b0 

0270 
0280 


0?90 


029  1 


0292 


CONTINUE 

CALL  JW0RD(2,TEMP) 

NEXT=IFINDN(TEMP, KNET) 

IF(NEXT.NE.O)  GO  TO  0220 

KEV=KEVfl 

IFfKFV.GT.255)  GO  TO  0230 

CALL  NAMIfMP(KNET(KFV,l),2) 

CALL  XlNTGR(NUMB,NEXT) 

KNET(KFV,3)=NEX  T 

HO  TO  O20  0 

CON r I NUt 

CALL  EPRRRR(3,«H 

CO  TO  0  20  0 

CONTINUE 

CALL  ERRPRR(?,*H 


S  T  A  T  I C  ,  0  ,  0  ) 


STATIC, 0,0) 


CON1  I 
CALL 
N1  =  IF 

I  F  f  N  1 

CALL 

GO  TO. 

COMTI 

CALL 

IF  (MA 

I  F  f  M  A 

I F  (  M  A 

CALL 

GO  TO 

COMTI 

CALL 

N2=IF 

IFCN2 

CALL 

GO  TO 

COMTI 

CALL 

GG  TO 

COMTI 

CALL 

M2  =  IF 

IFCN2 

CALL 

GO  TO 


NO 
J  W 
IN 
.F 
LP 

0 
NU 
SC 
TC 
TC 
TC 
ER 

0 
NU 
JW 
IN 
-N 
ER 

0 
NU 
SF 

0 
NU 
J  W 
IN 
.F 
SF 

0 


E 

0RD( 

DT(T 

Q.KT 

RRRR 

200 

E 

AMR  f 

H5(  1 

HS(  1 

HS(  1 

RRRP 

250 

E 

ORor 

DM(T 

E.O) 

RPpR 

250 

E 

TFRE 

250 

E 

OPOC 

ON(T 

Q.O) 

TFRF 

250 


2, TEMP) 

EVP,KTRMS,KTR) 
R)  GO  TO  0250 
(3,8H   STATIC, 0, 


0) 


5) 

,3HFND,3)  .EQ.  1  )  GO  TO  0200 
,5HINPUT,5) .EQ.l )  GO  TO  0260 
,6hOOTP!!T,b)  .EQ.  1  )  GO  TO  0280 
(5,8H   STATIC, 0,0) 


NUMP,TEMP) 
EMP, KNET) 

GO  TO  0270 
(4,8H   STATIC, I  WORD f NUMB, 1 ) ,0) 


(KTRNSCN1 ,2) ,M2) 


NUMB, TEMP) 
EVP,KMET) 

GO  TO  0260 
(KTRNS(N1 ,3) ,M2) 


CONTINUE 

CALL  ERRPRR(5,8H 

GO  TO  0200 


S  T  A  T  I  C  ,  0  ,  0  ) 


CONTINUE 

IFCIMFRST.NE.O)  GO  TO  02^2 

IMFRST=1 

NFREE1=NXTF 

COM  riNUE 

CALL  LISTX(KNET,KTRNS,KFRE,NXTF,KTIME,KEV,KTR) 

RETURN 

END 
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181 
182 
183 
18^ 
185 
186 
187 
188 
189 
190 
191 
192 
193 
19a 
195 
196 
197 
198 
199 
200 
201 
202 
203 
204 
205 
206 
207 
208 
209 
210 
211 
212 
213 
21  a 
215 
216 
217 
218 
219 
220 
221 
?i? 
223 
22a 
225 
226 
227 
l?^ 
229 
230 
231 
232 
233 

23a 

235 
236 
237 
238 
230 
2ao 


0295 
D9000 
D 


SUBRO 

BYTE 

C0MM0 

BYTE 
DIMEN 
DU  02 
S  T  R  I  N 

FORMA 
WRITE 
RETUP 
END 


JWORD(NUMBER, STRING) 

NUMB, TkORD(15, 10) 


UTINE 
I  WORD 
N/SCAN/ 

STRING 

SION  STRINGflO) 

9S  1=1,10 

G(I)=lWORD( NUMBER,  I) 

T ( '  J WORD: NUMBER, STRING: ',ia,2/,10Al) 

(7,Q000)  NUMBER, (STRING (I), 1=1, 10) 

N 


SUBROUTINE  SFTFRE(TPOINT,IVALUE) 

COMMON/NFT/  NET (255, a)  , NTRNS (255, 3)  ,  MFRE  (  999  ,  2  )  , 
1NXTF,KTIME,NEV,NTR 

FOR  TRANSITION  INPUTS  OR  OUTPUTS,  SET  UP  AND 
ENTER  VALUE  IN  ThF  CHAIN  POINTED  TO  BY  IPOINT. 


0300 


0310 


C 
C 
C 

c 

D9000 
D 


oaoo 


IF  f IPOINT. FQ.O) 
MEXT=IPOINT 


00  TO  0310 


CONTINUE 
NEXOLD=NEXT 
NEXT=NFRE(NEXT,2) 
IF(NExT.NE.O)  GO  TO  0300 

END  OF  CHAIN 
NXTF=NXTF+1 

IF (NXTF.GT.999)  CALL  ERRRRR(2,PH   SETFRE,0,0) 
NFRE(NEX0LD,2)=NXTF 
NFRECNX TF, 1 )=IVALUE 
RETURN 
CONTINUE 
NXTF=NXTFtl 
IPOINT  =  NX  TF 
NFRECNX  TF, 1 J  =  IVALUF 
RETURN 
END 

FUNCTION  IFIMDT(NAME,NTRNS,NTR) 

BYTE  NAMF,TtVp 

DIMENSION  NAME ( 10 ) , TEMP( 10) 

DIMENSION  NTRNS (255, 3) 

FIND  THF  TRANSITION  'NAME'  IN  THE  TABLE  I 
RETURN  NUMbFR 

FORM.ATf'  IFINDT:  NAME,NTR  '  ,2X,  10A1  ,2X,  la) 
WR I TF (7,9000)  (NAMF(T) , 1=1 , 10) ,NTR 
DU  oaoo  1=1,255 
IFTND1=I 

IFCNTRMSCI, 1) .NE.O)  CALL  GFTNAM ( NTRNS ( I , 1 ) , TEMP ) 
IF  fMA ICHC (NAME,  TF^P, 10).FQ.l)  RETURN 
CONTINUE 
DIDN'T  FIND  IT,  SO  CREATE  IT. 

NTR=MTR+1 

CALL  NAMEIT (NTRNS (NTR, 1) ,NAME, 10) 
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241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 

254 

255 

256 

257 

258 

25^ 

260 

261 

262 

263 

264 

265 

266 

267 

268 

269 

270 

271 

272 

273 

274 

275 

276 

277 

278 

279 

280 

281 

282 

283 

284 

285 

286 

287 

288 

289 

290 

291 

292 

293 

294 

295 

296 

297 

298 

299 

300 


C 

c 

r 

C 

09000 
D 


0500 
0510 


D9000 
0 


0550 


IFINDT=NTR 

TFfNTR.LE.255)  RFTURN 

CALL  tPRRRP(2,8H   IFINDT,0,0) 

RETURN 
FND 


FUNCTION  IFINDN(NAM£,NET) 
BYTE  NAME, TEMP 
DIMENSION  NAME(10),TEMP(10) 
DIMENSION  NET(255,4) 

FIND  THF  NAVE  in  THE  TA6LF 
RETURN  0  IF  NOT  THERE 

FORMATC  IFINON:NAME  '  ,10A1) 

WRITE(7,9000)  (NAME ( I ) , 1=1 , 1 0) 

IFINDN=0 

HO  0500  1=1 ,255 

IFCNET (I, 1 ) .NE.O)  CALL  GFT NAM ( NET ( I , 1 ) , TEMP ) 

IFfMATCHC(NAME,TEMP,10) .EQ.l)  GO  TO  0510 

CONTINUE 

RETURN 

CONTINUE 

IFINDN=I 

RETURN 

END 


FUN 
PYT 

DIM 
MAT 
FOR 
WRI 

no 

IF( 

CON 
MAT 
PET 
END 


CTI 
E  S 
ENS 
CHC 

m  a  r 

TF( 

055 
STR 
TTN 
CHC 
URN 


ON  MATCHCCSTRNG1 , STRNG2, KQUNT) 

TRNG1',STRNG2 

ION  STPNG1 (10) rSTRNG2(10) 

=  0 

(•  MATCHC:  • ,2( 10A1 ,2X)  ) 

7, 9UOQ)  (STRNG1 (T),I=1,10),(STRNG2(I),I=1,10) 

0  I=l,KOUNT 

NG1  (T  )  .NF.STRNG2(I)  )  RETURN 

UE 

=  1 


SUBROU 


0600 


^TIME  LISTX(NET,NTRNS,NFRE,NXTF,KTIME,NEVfNTR) 
BYTE  TEMP 
DIMENSION  TE^P(IO) 
DIMtNSIOM  NET (255, 4) , NTRNS(255, 3) , NFRE(999,2) 

AFTER  STATIC  HARDWARE  NFT  IS  IN,  DO  AN  ANALYSTS, 
FIRST  PRINT  SYMBOL  TABLP  DU^PS,  THEN  DO  STATIC 
CONFLICT  ANALYSIS  OF  THE  NETWORK 

FORMAT  (//,20X,  • STATIC -STRUCTURE-ANALYSIS ', 

//) 

IwRITF  (7,  0600) 

CALL  DUMP(NET,NTRNS,NFRE,NXTF,KTTME,NEV,NTR) 

WRITE(7,0600) 

RETURN 
END 
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301 
30? 
303 
304 
305 
306 
307 
308 
309 
310 
311 
312 
13 
14 
15 
16 
17 
18 
19 
320 
321 
32? 
323 
324 
325 
326 
327 
328 
12° 
330 
331 
332 
333 
334 
335 
336 
337 
33* 
339 
340 
341 
342 
343 
344 
345 
346 
347 
348 
349 
350 
351 
35? 
353 
354 
355 
356 
357 
358 
359 
360 


SUBROUTINE  DUMP (NET ,NTRNS, NFRE, NX TF, K TIME, NEV,NTR) 

RrTE  TEMP 

DIMENSION  TEMPUO) 

DIMENSION  NET(255,4),NTRNS(255,3),NFRE(999,2) 


0700  FORM 
1  '  EV 
2'-- 
FORM 
WRIT 
DO  0 
CALL 
WRIT 
CONT 
FORM 
IMP-  , 

FORM 

WRIT 
DO  0 
CALL 
WRT  F 
1  J  =  2, 
RETO 
END 


0710 


0720 
0730 

0740 


0750 


AT 
EN 
-0 
AT 
F( 
72 

G 
E( 
IN 
M 
/ , 
AT 
E( 
75 

G 
E( 
3) 
RN 


C/,2nx, 'NETWORK  ARRAY  DUMP    TIME  =  ',15, 

T3  ',/,lX,'     — NAME--   -MARKER-   --TYPE', 

UTPUT-   ',//) 

(X, 10A1 ,3110) 

7,0  700)  KTIME 

0  1=1, NEV 

FTNAMiNEKI,  1  )  ,  TEMP) 

7,0710)  (TEMP(TJK),IJK=1, 10) , (NET(I,J),J=2,4) 

Ut 

(/,20X,(  TRANSITION  TABLE  AND  FREE  SPACE  DU ' 

3X,'  --NAME--  INPUT  PTR.  OUTPUT  PTP   '  ,//) 

(X,  10A1  ,2110) 

7,0730) 

0  1=1, NTR 

ETNAM(NTRNS(I, 1 ) , TEMP) 

7,0740)  (TEMP(IJK)  ,IJK=1  ,  10)  ,  (NTRNSd,  J)  , 


S  U  B  R  0  U  T 

C0MMDN/ 

1 N  X  T  F ,  K  T 

COMMON/ 

COMMON/ 

COMMON/ 

BYTE  NA 

BYTE  TE 

DIMEMST 

0800  FORMATt 

OHIO  F  0  R  M  A  T  f 

1 • -NUMBF 

0*20  FORMAT ( 

WRITE  (7 

DO  0830 

CALL  GE 

CALL  GF 

IF  C I  .LE 

1MFPECI, 

IFCI.EQ 

IF  r I.GT 

1NFREU, 

0830  CONTINU 

0  «  4  0  F 0 P i« A  T  f 

Ofl 50  FOPMAK 

WRITE  (7 

DO  0P60 

0*60  WRITE  (7 

RETURN 

END 


INE  TDUMP 

NET/  NET(?55,4) , NT RMS f 255, 3 ) , NFRE (999 , 2 ) , 

IME,NFV,NTp 

SOFT/  JNET (255,4) , JTRNS (255, 3) , JEV, JTR 

DMP/  NFPEE1 

N AME 1 /N AMES ( 203 , 1 0 ) , NXTN AM 

MFS 

MP1, TEMP 2 

ON  TEMPI ( 1 0) ,TEMP?( 10) 

x,  ' •) 

//,?0X,  'FPEFSPACE  ',/,3X, 

R-   -EVENT-        --NEXT — ',//) 

X,  1  I  10, ?X,  10A1  ,  1  11  0) 

,0810) 

1=1 ,NXTF 
TNAM(NET(NFRE(I, 1),1), TEMPI) 
T NAM (JNET (NFRE (I, I) , 1),TEMP2) 

.NFREF1)  WRITE(7,08?0)  I , (TEMP  1 ( J) , J= 1 , 1 0 ) , 
2) 

.NFREE1)  WRITE(7,0800) 

.NFREE1)  WRITE(7,0820)  I , (TEMP2 ( J) , J=l ,  1  0) , 
2) 
t 

5X,  'NAMES   MXTNAMr '  ,  14) 
5  X  ,  1  0  A  n 
,0840)  N X  T  N  A  M 

1=1 ,NXTNAM-1 
,0850)  CNAMESCI, J) , J=l , 1 0) 
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361 

362 
363 
36^ 
365 
366 
367 
368 
369 
370 
371 
372 
373 
374 
375 
376 
377 
378 
379 
380 
381 
382 
383 
38^ 
385 
386 
387 
388 
3A9 
390 
391 
39? 
393 
394 
395 
396 
397 
398 
399 
400 

aoi 
ao? 
ao3 

404 
405 
406 
407 
408 
40Q 
410 
411 
41? 
413 
41U 
415 
416 
417 
418 
41P 
420 


SUBROUTINE  DYNAMO 

CO^MON/NE  T /  NET(255,4),NTRNS(255,3),NFRE(999,2) 
INXTF,KTIME,NEV,NTR 

COMMON/DYN/  LOOM  (255),LnOK?(?55) 
COMMON /SCAN/  NUMB,  T'aORD(15,10) 

INTERPRET  DUNAMIC  COMMANDS  AND  RUN  SIMULATION 


IFCKTIME.EQ.O)  KTIME=1 


0^00 

0910 

0920 
U930 
0940 


CONTINUE 

CALL  SCANK(5) 

TF (MATCHS ( 1 ,  3HFNO 

IF (MATCHS( 1 , 

TF(MATCHS( 1 

IF(MATChS( 1 

CONTINUE 

CALL  ERRRRR(5,«H 

GO  TO  090u 

CALL  MARKET 
CO  TO  090  0 
CALL  SETOUT 
GO  TO  09  0  0 
CALL  EXEQ 
GO  TO  0900 
END 


3).EQ.l)  RETURN 
4hMAP*,4) .EG. 11  GO  TO  0920 
,6H0UTPUT,6).EQ.l)  GO  TO  0930 
,7HExECUTE,7) .EQ.l )  GO  TO  09a0 

DYNAMO,  0,0) 


SUBROUTINE  ViARKET 

COMMON /NET/  NET (255,4) , NTRNS ( 255 , 3 ) ,NF RE (999,2)  , 
1NXTF,KTIME,NEV,NTR 
CUMMON/5CAN/  MIMB,  I  WORD  (  15,  10) 

BYTE  TEMP 
DIMENSION  TfPUO) 

MARK  AN  EVENT  ^  I TH  THE  DESIRED  VALUE 


CALL  JW0RD(2, TEMP) 
N1  =  IFINDN(TEMP,NE  I  ) 

IF (N1 .NE.O)  GO  TO  1000 
CALL  ERRPRP(4,8H   MARKET, 
RE  TORN 
1000  CONTINUE 

CALL  XINTGP(NUM(3,  IVALUE) 
NET (Ml, 2 )=I VALUE 
RETURN 
END 


IW0RDC2, 1) ,0) 


SUBROUTINE  SETOUT 

COMMON/NET/  NET(?55,4),NTRNS(255,3),NFRE(999,2), 
lNXTE,KTIMt,NE\/,NTR 
BYTE  I  WORD 

COMMON  /SCAN/  NMMB,  I'aORD(  15,  10) 
BYTE  TEMP 
DIMENSION  TE^PUO) 
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421 
422 
423 
42a 
425 
426 
427 
428 
429 
430 
431 
432 
433 
434 
435 
436 
437 
438 
439 
4a0 
441 

4a? 

443 

4aa 
4a5 
aa6 

447 
448 
449 
450 
451 
452 
453 
454 
455 
456 
457 
458 
459 
460 
461 
46? 
463 
464 
465 
466 
4b7 
468 
469 
470 
471 
472 
473 
474 
47S 
476 
477 
4  7  fl 
479 
480 


1  100 


SET  OUTPUT  FLAG  ON  DESIGNATED  EVENT 

CALL  JWOPD(NUMB,TEMP) 

N1  =  IFINDN(TE~MP,NET) 

TF  CN1  .ME.O)  GO  TO  1100 

CALL  EPRRRR(4,Ph   SETOUT , IWORD (NUMB, 1) , 0) 

RETURN 

CON1 TNUE 

N  E  T  ( N  1  ,  a  )  =  1 

RETURN 

END 


SUBROUTINE  EXEQ 

COMMON /NET/  NET (255/ 4) , NTRMS ( 255 , 3 ) , NFRE (999,2)  , 

NXTF,KTIME,NEV,NTR 

COMMON /SOFT/  JNET(?55,a) , JTRNS (255, 3) , JEV, JTR 

EXECUTE  THE  REQUESTOR/SERVER  NETWORK 


CALL  XINTGR(?, I  TIME) 
KLIMIT=KTIME+ITIME 

1?00  CONTINUE 

IF(KTIME.GE.KLTMIT)  RETURN 

CALL  EXEG1 U NET, JTRNS, NFRE, NXTF, JEV, JTR,1,T GO, 
IK  TIME) 

IFdGCEQ.  1)  GO  TO  1  POO 

IFfKSUFT (IGU)  .EO.O)  RETURN 

CALL  HWGO 

CALL  EXEQ1(NET,NTRNS,NFRF,NXTF,NEV,NTR,0,IGO, 
IK  TIME) 

GO  TO  1200 

END 

SUBROUTINE  E VEO 1 ( KNET , I T RN , NFRE , K TF , I E V , ITR,TFUNC, 


IIFIRE,KTIME) 

BYTE  IFMP 

DIMENSION  TEMP(IO) 

COMMON/DYN/  LOOM (?55) ,L00K2(255) 

DIMENSION  KNET  (255,  4)  ,  URN  (255,3)  ,  NFRE  (999,  2) 

DIMENSION  KPRINK255) 


1300 


EXECUTE  THE  SPECIFIED  NETWORK  FOR  ONE  CLICK 

IFUNC  =  1  --)  SOFTWARE  NET, 

IFUNC  =  0  — )  HARDWARE  NET 

IFIRE  =  0  --)  NOTHING  FIRED  THIS  TIME 

IFIRE  =  1  --)  ONE  OR  MQ9E  TRANSITIONS  FIRED 


IFIRF=0 

FORMAT  (X,  •Ti^Er' ,  14,  •  \«  ) 
IFCIFUNC.EQ. 1 )  GO  TO  1310 
WRT1EC7, 1 300)  KTIME 
CALL  H  W  R  A  |\j  D 


1310  CONTINUE 
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aet 
48? 

483 
484 
485 
486 
487 
488 
489 
490 
491 
49? 
493 
494 
495 
096 
497 
498 
499 
500 
501 
50? 
503 
504 
505 
506 
507 
508 
509 
510 
511 
51? 
513 
514 
515 
516 
517 
518 
519 
5?0 
521 
5?? 
523 
524 
525 
526 
527 
52* 
529 
530 
531 
532 
533 
534 
535 
536 
537 
53* 
539 
540 


1320 


1330 


1340 


1360 


1370 


1380 


CALL  MARKER(L00K1,KN 
DO  1320  1=1, IEV 
KPRINT(I)=0 

CONTINUE 


FT,ITRN,NFPE,KTF,IEV,ITR) 


DO  1390  T=1,ITP 
CHECK  ^HICH  TRANSITIONS  ARE  READY  TO  FIRE  i 
EXECUTE 
CALL  MARKER (LOOK?, KNET , ITRN, NFRE,KTF , IEV , I TR) 
IFCLOOKKD.EQ.O  .AND.  LOOK?  ( I  )  .  EQ  .  1  )  GO  TO  1390 
IF(LOOKlf  D+L00K2CI)  .EQ.  0)    GO  TO  1390 
IFCLOOK1CI) .EQ.L00K2CI))  GO  TO  1330 
CALL  EPRPRR(6,7H    EXEQ, ITRN ( I , 1 ) , 0 ) 
GO  TO  1390 


CONTINUE 
FlRluG  A 


TRANSITION  -  UNMARK  INPUTS,  ^ARK  OUTPUTS 


IFIRE=1 

NEXT  =  ITRN (1,2) 

CONTINUE 

IF(NEXT.EQ.O)  GO  TO  1350 

NEXOLD=NEXT 

MEX  r=.\IFRE(NEXT  ,2) 

CHECK  IF  NU  TOKENS 
IF(KNET(NFRE(NEX0LD,1),2).EQ.0) 

IF  MO  MORF  TOKENS,  HAVE  TO  BACK  OUT  OF  TRANSITION 
KNETCNFRECMEXOLD, 1 ) , 2)=KNET (NFRE (NEXOLD, 1 ) ,2) -1 
GO  TO  1340 


MAYRE  USED 


ON 
GO 


THIS  TRANSITION 
TO  1370 


1350  CONTINUE 


NEXT=ITRN(I,3) 

CONTINUE 

IF(NFXT.FQ.O)  GO  TO  1390 

NEXOLD=NFXT 

MEXT=NFRF(NEXT,2) 

KNFT  CNFRECNEXOLO, 

If-  (IFUNC.EQ.  1  )  CALL 

IF(IFUMC.EO.O)  CALL 

KPRIMTfNFRE (NE*0LD, 

GO  TO  1360 


1) 


,?)=KNET(NFRE(NEXOLD,n,2)+l 
RSINfKNET(NFRE(NEXOLD,l),l)) 
RSOUT(NFRE(NEXOLD, 1 ) ) 

1))  =  1 


THIS  TRANSITION  IS  WIFRD. 


CONTINUE 

REPLACE  SOME  TOKENS, 
ISTOPD=NEXOLD 
MEX  1  =  ITRN (I,?) 
CONTINUE 

IF(NEXT.EQ.ISTOPD)  GO  TO  1390 
NEXOLO=NFXT 
NEXT=NFRE(MEXT ,2) 

KNE KNFR E (MEX OLD, 1 ) , 2) =KNET (NFRE CNEX OLD, 1 ) ,2)+ 1 
GU  TO  1380 

END  OF  RAK-UP  PROCESS 


1390  CONTINUE 

DO  139?  J=l , IEV 

1391  F0RMATr5X,,*****FVFNT 
1  •*****'  ) 


1  0A1 


MARKED  WITH 


1110, 
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CALL  GETNAM(KNET(J, 1),TEMP) 
IFCKPRINT(J)  .EQ.l  .AMD.  KNET  ( J,  4)  .NE.O) 
1        toRT IF(7, 1 391 )  f TFMP(K) ,K=1 , 10) ,KNET(J,2) 
1392  CONTINUE 

IF(IFUNC.EQ.O)  KTI^E=KTIME+1 

RETURN 

END 

SUBROUTINE  HWGO 

COMMON /NET /NET (255, 4) , NTRNS (255, 3) , NFRE (999, 2) , 
1MXTF,KTIME , NF V , NTR 
COVMON/CTRLR/  IMOOE , ICQ (250 ) , ICQPTR 

MARK  AS  MANY  HARDWARE  UNITS  AS  DESIRED 
(ACCCORDING  TO  OUTSTANDING  Si*  REQUESTS) 
NOT  TO  EXCEED  THE  LTN'TT  OF  ••IMODE*. 

THEN  SHIFT  UP  THE  QUEUE,  ICQ/  AND  RESET  ICQPTR 

IF  ICQPTk  =  0  NOTHING  TO  DO,  SO  RETURN... 
IF  (ICQPTR. EQ.O)  RETURN 

CO  laoo  I=1,TCQPTR 

NET ( ICG (I)  ,  2)=NET(TCO(T)  ,2)  +  l 

J=T 

IF(I.-EO.IMODF)  GO  TO  1  a  1  0 

CONTINUE 


1400 

lain 


ia2o 


ison 


CONTINUE 

REPACK  QUFUF. 
PO  142n  I=l,TCGPTR-J 
ICOCT )=ICQ(J+I) 
CONT INUE 
ICQPTR=ICQPTR-J 

RETURN 

END 


SUBROUTINE    HWRAfviD 
COMMON/NFT/    NET(255,4) 

COMMON/RAivjD/    randp 

CHECK  RANDOM  EVENT  AND  MARK  IT  PROb Ah IL I  ST  I C ALL Y . 

PROB=RAN(I 1 , 12) 

TFfPRUR.LT  .KAljDP)  NET  (  255  ,  2  )  =NF  T  (  255  ,  2  )  +  1 

RETURN 
END 

SUBROUTINE  M ARKER (KRAY,NFT,NTRNS, NFRE, MxTF,NEV, NTR) 
DIMENSION  MET(255,4),NTRNS(255,3),NFRE(999,2) 
DIMENSION  KRAYC255) 

DO  150  0  1=1 , NTR 
KRAYf I)=n 
CUNT  INUE 
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601 

60? 

603 

604 

605 

606 

607 

608 

609 

610 

611 

61? 

613 

614 

615 

616 

617 

618 

619 

620 

621 

622 

623 

62  4 

625 

626 

627 

628 

629 

630 

631 

63? 

633 

634 

635 

636 

637 

638 

639 

640 

641 

642 

643 

644 

645 

646 

647 

648 

649 

650 

651 

65? 

653 

654 

655 

656 

657 

65* 

659 

660 


DO  15  30  1  =  1,  MR 
K  1  =  0 
K2  =  0 

MEXT=iMTRNS(I  ,2) 
1510  CONTINUE 

IF f NEXT.EQ.O)  GO  TO  1520 

NEXOLD=NEXT 

NEXT=NFRE(NEXT,2) 

K2=K2+1 

IF(NET(NFRE(NEX0LD,1), 2).NE.O)  K  1  =K  l  ♦ l 

GO  TO  1510 

1520  CONTINUE 

IFCK1.FQ.k2)  K  R  A  Y ( I )  =  1 

1530  CONTINUE 

RETURN 
END 

SUBROUTINE  PGMNET 

COMMON /SOFT/  JNET(255,4) , JTRNS C 255 , 3 ) / JEV , JTR 

THE  SOFTi\AKF  NET  BUILD  ROUTINE... 
FIRST  RENAME 

THEN  CONTINUE  REBUILDING  ThF  NET 
CALL  STATIC (JNET, JTRNS, JEV, JTR) 

NOirf    LOUK    FOP    THE    BEGIN    STATFMENT... 
T  =  TFTlNiD»\f  lOHBtGIN  ,JNET) 

IFCI.NE.O)     GO    TO     1600 
CALL    ERRRRR(8,6HPG^NFT,0) 

1600  CONTINUE 

MARK  THE  SOFTWARE  BEGIN  EVENT 
JNET(I,2)=1 
RETURN 
END 

'SUBROUTINE  RSIM(NAME) 
BYTE  TEMP 
DIMENSION  TEWPC10) 

COMMON /NET/  NET(?55,4)fNTRNS''255,3),NFRtC999,2), 
1NXTF,KTIME,NEV,NTR 
COMMON/SOFT/  JNET (255, 4) , JTRNS (255, 3) , JEV, JTR 
COMMON/RSTAdL/  IRSC90,3) 

THE  RFQUESTOR/SFRVEP  INTERFACE  TABLE 

IRS(M,1)  --)  POINTED  TO  NAME  OF  SOFTwARF  FVFNT 

REOUFSTIMG  SERVICE 
IRSCM,2)  --)  START  TIME  OF  REQUEST. 
IRS(M,3)  --)  HARDWARE  UNIT  NUMBER  REQUIRED. 

COMMON /CTRLR/  IMODF,ICQ(?50),ICQPTR 
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COMMON  bLGCK  CTKLR  CONTAINS  INFO  REGARDING 
HARDWARE  REQUESTS,  AMD  EXISTS  SO  THAT  THF  U    OF 
RtQUFSTS  PFR  mi^or  CYCLE  CAN  LIMIT  AS  DESIRED. 
REQUESTS  STACKED  IN  TCQ,  THE  QUEUE,  AND  SERVICED 
AS  POSSIBLE,  A  MAX  OF  IMODE  EVERY  MINOR  CYCLE. 


ENTER  NAME  IN  THE 
REMOVE  SHFT  TOKEN. 
IS  TYPE  0  If'HlCH  13 


TABLE,  PLACE  HW  IN  QUEUE,  THEN 
(DO  NOTHING  IF  SOFTEVENT 
A  NULL  EVENT  FOR  PRECEDENCE) 


CALL  GETNAM(NAME,TEMP) 

NUMBER = J NET( IFTNDN(TEMP, JNET)  ,3) 

IF (NUMBER. EQ.O)  RETURN 


1700 


1710 


1720 
1730 


PO  1700  1  =  1, <3l) 
IF(IRS(I, 1) ,EQ 

CONTINUE 

CALL  f PRRRR( 1 1 


0)  GO  TO  1710 
4HRSIN,TEMP,0) 


CONTINUE 

DO  1720  J=1,NEV 

TF(NET(J,3) .EG. NUMBER)  GO  TO  1730 

CONTINUE 

CALL  ERRRRP(9,4HRSTN,NAME, 0) 

CON TTNUE 

TCQPTR=iruPrR+1 

TF(ICQPTP.GT.2S0)  CALL  ERRRRR ( 1  1  ,  1  OHRSIN  (ICO), 0,0) 

TCO(  ICQPTR)=J 

J=TF  INDN(TFMP, JNET) 

JNET(J,2)=0 

IRS(T, 1 )=NAME 

IRSCIr 2)=KTIVE 

IRS( I ,3)=NUMBEP 


1740  FORMAT (5X,  •  *PROGRAM  EVENT 


10A1 


REQUESTS  Hw 


•  SVCS  ' 
WRITE (7, 
RETURN 

ENH 


,  115) 
1710) 


(TEMP(K) ,K=1, 10) ,KTI^E 


SUBROUTINE  RSOUT ( NUMBER ) 
PYTE  TEMP 

DIMENSION  TE^P(IO) 
COMMON/NET/  NET (255, 
1NXTF,KTIME,NFV,NTR 
COWMON/SOFT/  JMETC255, 
COMMON/RST  AbL/  1PS(90, 


U)  ,  NTRNS(255,3)  ,  NFRE (999,2) 


4) 
3) 


JTRNS(2S5,3) , JEV, JTR 


NET  TRANSITION  NUMBER  (HARDWARE)  HAS  COMPLETED, 
SEE  IF  TTS  TYPE  IS  .LT.  0  (A  UNIT  FINISH  EVENT), 
AND  IF  SO,  SEF  TF  A  SOFTWARE  EVENT  WAS  EXECUTING. 
IF  SO,  ON  A  FTFO  PASIS,  COMPLETE  THE  SOFTEVENT, 
PRINT  A  MF3SAGE,  REPLACF  THF  TOKEN  IN  THE  SOFTNET 
AND  CONTINUE. 

IF (NET (NUMBER, 3) .GE.O)  RFTURN 

1*00  FCPMAT(5X, • *PROGRAw  EVENT  ',10A1,'  COMPLETES  ',115) 
J  =  0 

K  =  l  0000 
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721 
72? 
723 
72a 
725 
726 
727 
728 
729 
730 
731 
73? 
733 
73a 
735 
736 
737 
73« 
739 
740 

7a  1 

7a? 

743 

7aa 

745 

746 

747 

748 

749 

750 

751 

75? 

753 

75a 

755 

756 

757 

758 

75° 

760 

761 

76? 

763 

7t>4 

765 

766 

767 

768 

769 

770 

771 

77? 

773 

774 

775 

776 

777 

77* 

770 

780 


1810 


1^00 


1920 


1921 


DO  1*10  1  =  1,90 
TFCIRSf  1,3) .ME 
IFf  IRS(I,2) 
J=T 

K=IRS(I,2) 
CONTINUE 


(NET(NUMBFR,3)*-1) ) 
Gt.K)  GO  TO  1810 


GO  TO  1810 


IFCJ.EQ.O)  RF  TURN 
FOUND  IT  

MARK  SOFTEVENT,  UNMARK  HAPDEVFNT 
CALL  GETNAM( IRS(J, 1 ) , TEMP) 
K=IFINDN( TEMP, JNE 1) 
CALL  GETNAM(JNETfK,l),TEMP) 
lrjRTTE(.7,1800)  (  TEMP  (L  )  ,L  =  1 ,  1  0 )  ,  KTIME 
JNET  CK,2)=1 

NET (NUMBER, 2 )=NET ( NUMBER, 2 )-l 
IRSCJ, 1 )=0 
IRS(J,2)=0 
IKS(J,3)=0 
RETURN 
END 


FUNCTION  KSOFT C irilwMY ) 
COMMON/RSTABL/  IRS (9 0,3) 

COUNT  NUMBER  OF  ACTIVE  PROCESSES  IN  TAbLE 

J  =  0 

DO  1900  T=l,9o 

TFCIRSf I, 1) .Mi. 0)  J=J+1 

CONTINUE 

KSOFT=J 

R  E  T  U  P  N 

END 


SUBROUTINE  NAME IT (I POINT, STRING, KOUNT) 


ENTER  NAMF  OF  EVENT  OR  TRANSITION  'STRING' 
INTO  THE  GENERAL  NAME  TABLE.  RETURN  A 
POINTER  TO  ITS  ENTRY  'IPOINT'. 


BYTE  NAMES, STRING, IBLANK 
COMMON/NAME  1 /NAMES (203, 10) ,NXTNAM 

DIMENSION  STRIMGflO) 
DATA  NXTNAM/1/ 
DATA  IPLA.MK/1H  / 

ERASE  THE  ENTRY 
DO  1920  T=l , 1 0 
NAMES(NXTNAM,I)  =  IBl  ANK 

CPPY  IN  THE  DATA 
DO  1921  1=1, KOUNT 
NAMES ( NX TN AM, I)=STRIMG(I) 

BUMP  THE  POINTER  AND  TEST  FOR  OVERFLOW 
TPniM T=NX TNAW 
NXTNAM=NXTNAM+1 
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781 

78? 

783 

78a 

785 

786 

787 

788 

789 

790 

791 

792 

793 

79a 

795 

796 

797 

798 

799 

800 

801 

803 

P03 

8oa 

805 
806 
807 
808 
809 
810 
811 
812 
813 
8i  a 
815 
816 
817 
818 
819 
820 
*2\ 
822 
823 
8£4 
825 
826 
827 
828 
829 
830 
831 
832 
833 
834 
835 
836 
837 
838 
839 
840 


IFCNXTNAM.GT.203)  GO  TO  1922 
D9000  FORMAT ('  NAME1T:  IPOINT, STRING  '  ,  I  4  ,  2X , 1  A  1 0  ) 
D      WRI IF (7,^000)  IPOINT,  (STRING  (I), 1  =  1, 10) 

RETURN 

PROBLEM 


192? 
1923 


1940 
D9000 
D 
C 
C 
C 


C 

C 

19d0 
C 

09000 
D 


GOT  A 
CONTINUE 
FORMAT  C  ■ 
1'  NAME  II 
WRTTF 16, 1923) 
CALL  EXIT 
END 


**NAME  TABLF  OVERFLOW  DETECTED  BY', 
(FATAL)') 


SUBROUTINE  GETNAW(TPOI NT, STRING) 

GET  THE  NAME  flO  BrTE  STRING)  POIMTFD  TO  BY 
"IPOINT"  AND  RETURN  IT  IN  "STRING" 

BYTE  NAMES, STRING 

COMMON/NAME1 /NAMES (203, 10) , NXTNAM 

01  MENS  TOM  STRING(IO) 

DO  1^4  0  1=1,10 
STRING(I)=NAN'ES(IPOINT,I) 

FORMATf'  GETNAM:  IPOINT, STRING  ' , I  4 , 2/ ,  1  A  1  0  ) 
fcRITE(7,Q00u)  I  POINT, (STRING (I), 1  =  1, 10) 

WASN ' T  THAT  SI^PL  E? 

RETURN 
END 


SUBROUTINE  NAMINP( I  POINT, NUMB) 

NAME  IT  FROM  Aim  INPUT  SCANNER  WORD 

BYTE  I  WORD 

CO^MON/SCAN/NIJMbER,  IWOPD(  15,  1  0) 

BYTE  TEMP 
DIMENSION  TtMp(lO) 

DU  I960  1=1,10 

TEMP( I )=I WORD (NUMB, I ) 

FORMAT  ('  N  AMI  IMP:  NUMB,STPING  '  ,  I  4  ,  2X  ,  1  A  1  0  ) 
WRITE (7, 900  0)  NUMB, ( TE^P ( I ) ,  I  =  1 ,  1  0  ) 
CALL  NAMFITCIP01NI , TEMP, 10) 

RETURN 
END 

SUBROUTINE  SCANR(LONIT) 


FREE  FORMAT  INPUT  POUTTNE.    READS  AN  80  BYTE 
RECORD  FROM  LOGICAL  UNIT  "LUNIT"  AND  STORES  UP 
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841 
8q? 
843 
844 
845 
846 
847 
848 
849 
850 
851 
85? 
853 
854 
855 
856 
857 
858 
859 
860 
861 
86? 
863 
864 
8b5 
866 
867 
868 
869 
870 
871 
87? 
873 
874 
875 
876 
877 
878 
879 
880 
881 
88? 
883 
884 
885 
886 
887 
888 
889 
890 
891 
89? 
893 
«94 
895 
896 
897 
898 
«99 
900 


TO  15  BLANK  DELIMITED  TOKENS  (LEFT  ADJUSTED) 
IN  BYTE  ARRAY  "IWORD". 

NUMERICAL  VALUES  CAN  BE  REFORMATTED  FROM  BYTE 
STRINGS  TNTO  INTEGER  AND  FLOATING  POINT  VALUES 
THRU  THE  SUBROUTINES  "XFLOAT"  AND  "XINTGR". 

BYTE  IWORD, ISC, 1BLANK 
COMMON/SCAN/IMUMBER,  IWORD  MS,  10) 
RYTE  NPUFFR 

COMMON/SCAN  1 /NPUFFR(RO) 
DATA  ISC/1" ;/ 
DATA  IBLANK/1H  / 
DATA  N  E  G  F  /  0  / 
DATA  KLINE/0/ 
2001  KLTNE=*LINE+t 
2000  FORMATC80A1) 

BEGIN  BY  READING  A  LINE  OF  80  BYTES 

READ (LUNIT, 20  00 , END=20  35 , ERR=2035)  (NBUFFRf I) , 
11  =  1  ,80) 
200?  FORMA ( (X, 1T4, •  -  ',80A1) 

WRITE (7, 20 02)  KLINF, (NBUFFR ( I ) , 1=1 ,80) 

SET  POINTER  TO  EIPST  CHARACTER  IN  THE  BUFFER 
IPO I NT =1 

NOW  PROCESS  THE  FTRST  15  TOKENS  DELIMLTED  BY 

EITHER  A  BLANK  (OR  MULTIPLE  BLANKS)  OR  A 

SEMICOLON. 

DO  2025  NUWBER=1  ,  15 
IELAG=0 

SET  IWOPD(NUMBER,X)=IBLANK(SET  WORD  TO  ALL  BLANKS) 
PO  2005  1=1,10 
2  0  05  I WORD (NUMBER, I)=TBLANK 

STAPT  SCAM  OF  LINE  FROM  POINTER  ON,  FIND  N0N-8LANK 
KOUNTsl 

"KUUNT"  KEEPS  TRACK  OF  NO.  OF  CHAR.  IN  THE  TOKEN 
DO  201^  KPOIN r=IPOINT,80 

IF(NBUFFRCKPOINT)  .NE.IBLANK  .AND.  MBUFFR (KPOTNT) 
1. ME. ISC)  GO  TO  2010 
IP (IELAG.EO.O)  GO  TO  2015 
TF(1FLAG.E0.  1  )  GO  TO  2020 

GOT  SOMETHING,  SO  PROCESS  IT . 

2010  CONTINUE 
IFLAG=1 

IWORD(NUMBER,KOUNT)=NBUFFR(KPOINT) 
KOUNT=KOUNT+ 1 

TFCKOUNT.GT.  10)  GO  TO  ?0?0 
2015  CONTINUE 


202  0  CONTINUE 

END  OF  TOKEN  FOUND,  RESET  SOME  POINTERS 
T  P  0  I  N  T  =  K  P  0  T  N  T  +  1 
TF  f  IPOINT.GT.80)  GO  TO  2030 

2025  CONTINUE 

END  Of     BASIC  TOKEN  GETTING  LOOP 

20  30    NUM6FR  =  NIJMBER-1 

IFCNUMBER.EQ.O)    GO     \0    2001 
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2035 

2040 


2050 


IF  f 
RET 

C0*! 

FOR 
113) 
WRI 
NEO 
IF( 
NUM 
PET 
END 


20a5 


2055 
20b0 


MATCHSU, 'COMMENT: • ,8). EQ.l)  GO  TO  2001 

U»N 
TINUE 

END  OF  FTLE  PR  I/O  ERROR  DETECTED 
MAH'  EOF  OR  ERROR  ON  SCANNER  INPUT  FROM  UNIT  ' 

TE(7,204  0)     LUMT 

F=NFOF+l 

NEOF.GE.3)     CALL    EXIT 

BER  =  0 
URN 


SUBROUTINE  XFLOAT (NwORD , FWORD) 

CONVERT  THE  EimTRY  IN  ARRAY  IWORD  («  NWORD)  TO 
STANDARD  FLOATING  POINT  REPRESENTATION,  RETURN 
IT  AS  "FWORD". 

BrTE  IWORD 

COMMON /SCAN /NUMBER, IWORDC 15, 1 0 ) 

RYTE  T  S  T  R  TJ  G 
DIMENSION  TSTRNGC10) 

COPY  STRING  (TO  ALLO^  COMPILER  TO  STORE  THE  ARRAY 

HOWEVER  LT    WANTS  TO) 
DO  20a5  1  =  1 , 1 0 
TSTRNG(I)=IWORD(NWORD, T) 

DEFINE  THE  FORMATS: 
FORMAT ( IF  10. 3) 

DO  IT  i 
DECODEflO,2050,TSTRNG)  FWORD 
RETURN 
END 

SUBROUTINE  XINTGRCNWORD, IVALUE) 

CONVERT  THF  FNTRY  IN  "TWORD"  TO  INTEGER 
RETURN  INTFQER  "IVALUE" 

RYTE  I W  Q  P  D 

COMMON /SCAN/NUMBER, I WORD (15, 10) 

BYTE  TSTRNG 
DIMENSION  TSTRNGflO) 
BYTE  IBLANK 
DATA  JBLANK/1H  / 

COPY  THE  STRING  (SA^E  PROBLEM  AS  ABOVE) 
DO  2055  1=1,10 
KOUNT=I 

TSTRNGf  i  )  =  I/jORn(M^ORD/  I  ) 
II-  C  IWORDCiMWORUr  I)  .EQ.IRLANK  )  GO  TO  2060 

WE'VE  FOUND  THE  END  OF  THE  LINE 
CONTINUE 
CONTINUE 
KOUNT=KOUNT-l 
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9fel 

962 

963 

964 

965 

966 

967 

9b8 

969 

970 

971 

97? 

973 

97^ 

975 

°76 

977 

978 

97° 

980 

981 

982 

983 

984 

985 

986 

987 

988 

969 

990 

991 

°92 

993 

99  4 

995 

996 

997 

998 

999 

1000 

1001 

1002 

1003 

1  004 

1005 

100b 

1007 

1006 

1009 

1010 


c 


2  0  65  FORMA!  (1110  J 

DECODE (KOUNT, 2065, TSTRNG)  I  VALUE 

RETURN 

ENO 


20 


101 
101 
101 
101 
101 
101 
101 
101 
101 


FUNCTION  MATCHS(NUMB,STRING,NCHAR) 

THIS  FUNCTION  DETERMINES  IF  SCANNER  TOKEN 
TwpRD(NUM6)  MATCHES  THE  CHARACTERS  IN  "STRING" 
M  LEAST  FOR  THE  FIRST  "NCHAP"  CHARACTERS. 

IF  THtPE  IS  A  MATCH,  IT  RETURNS  THF  INTEGER  "1" 
NU  MATCH  RETURNS  "0". 

BYTE  IWUPD 

COMMON /SC AM/ NUMBER, I  WORD f 15, 1 0) 

BYTE  STRING 

DIMENSION  STRING(IO) 

^ATCHS=0 

TEST  THE  STRINGS... 
DO  2070  1=1 ,NCHAR 

IF (I WORD (NUMB,  I  )  .NE  .STRING  C I  )  )  RETURN 
7  0  CONTINUE 

IF  YOU  GET  HERE,  THEY  WERE  THE  SAMF... 
MATCHS=  1 
RETURN 
END 


SUBROUTINE  ERRRRP(KIND,KALLER, NAME, MARK) 
COMMON/RRR/  «SG ( 1  1) 

MSG(N)=FATAL  FLAG  (l--)FATAL) 
BYTE  KALLER,NAMF. 
DIMENSION  KALLERUO)  ,NAME(10) 

MSG( I )=1 

MSG(2)=1 

MSGf 3)=0 

MSG(4)=0 

MSG(5)=0 

MSG(6)=0 

MSGf 7)=0 

MSG(8)=1 

MSG(9)=1 

MSGC10)=0 

MSG( 1 1 )=1 


1020 


101 
102 
103 
104 
105 


DETECTED 


(FATAL)   ',1A2) 
,112,'  DETECTED 


ER°UR  ',112 

BEGIN 
i  p  ^  q (jp 

O'vFRFLO/v  (FATAL)  ' ,1A2) 
ERROR  ',11?,'  DETECTED 
NAME  DUPLICATION   (IGNORED)    ',1A2) 
FORMAT (5X, 1A2,  'FRRUR  ',112,  '  DETECTED 
,'  ',10A1,»  UNDEFINED  ( T GMURED ) • , 1 A2 ) 
F0RMATC5X, 1A2, 'ERROR  ',112,'  DETECTED 


F0RMAT(5X, 1A2, 
'  MISSING  SECT 
FORMAT (5X,  I  42, 
•  SYMBOL  TARLF 
F0RMAT(5X,1A2, 


BY 

BY 
BY 
BY 
BY 


,  10A1, 
,  10A1, 
,  10A1, 
,  10A1, 
,  10A1, 
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210b 
2107 
2108 
2109 
211  0 
21  1  1 


•  — SYNTAX  ERROR-- 
FORMAT (5x, 1 A2, 'ERROR 


2121 


2122 


2123 


212a 


2125 


212b 


2127 


2128 


DYNAMIC 
FORMAT (5X, 
1  A2) 
FORMATC5X , 

•  NO  PEC  IN 
FORMAT (SX 


CONFLICT 

1 *2, '   EVENT 


(TGNORED)  ',1A2) 
, 112, •  DETECIED  BY 
' , 10A1 , 1A2) 

'  ,  I  0  A  1  ,  •  MARKED 


1 12, '  DETECTED  BY 
fSOFTNFT)  •  ,  1A2) 
1 12, '  DETECTED  BY 


1 A2, 'FRPOP   , 

EVENT  FOUND 
1 A2, 'ERROR  • 
NON-EX  1ST.  Hw  UNIT 
FORMATlSX,  1  A?,  'ERPOP  ',112,  '  DETECTED  BY 

•  ERROR- 10 BAD-CALL-TQ-ER'  ,  1A2) 

FORMAT (SX,  IA2,  'ERROR  ',112,'  DETECTED  BY 
'  R/S  TAbLE  OVERFLOW    (FATAL)   ',1A2) 


REQUESTED 

I   1T2   • 


1  A2) 


10A1, 

',1110, 

l^OAl, 

10A1, 

10A1, 

10A1, 


KSTAR=2H** 


IF(K 
IF(K 
IF(K 
IF(K 
IF(K 
IF(K 
1F(K 
IF(K 
IF(K 
IF(K 
IF(K 
T 
WRIT 
1F(M 

CALL 

CONT 
WRIT 
IF(M 

CALL 

CONT 
WRIT 
IF(M 
CALL 
CONT 
WRIT 
IF(M 
CALL 
CONT 
WRIT 
I F  ( M 
CALL 
CONT 
WRIT 
I  F  (  M 
CALL 
CDNT 
WRIT 
IF(M 
CALL 
CONT 
WPIT 
IF(W 
CALL 
CONT 


IND. 
IND. 

IND. 

IND. 

IND. 

IND. 

IND. 

IND. 

IND. 

IND. 

IND. 

HEN 

E(7, 

SG(K 

EXT 
IMUE 
E(7, 
SG(K 

Ex! 
INUE 
E(  7, 
SG(K 

EXT 
INUE 
E(7, 
SG(K 

ExT 
INUE 
E(7, 
SG(K 

EXI 
INUE 
E(7, 
SG(K 

FXT 
INUE 
E(7, 

SH(K 
FXI 
1NUF 
E(7, 
SG(K 
EXT 
INUE 


LT 

ED 
EQ 
EQ 
EQ 

EQ 
EQ 
EQ 
EQ 
EQ 
EQ 


KIND 
21  11 
IND) 

r 

2101 
IND) 
T 

2102 
IND) 

T 

21  03 
IND) 
T 

2104 
IND) 
I 

2105 
IND) 

r 

2]  06 
IND) 
I 

2107 

IMD) 

T 


.OR.    KIND. GT. in    KIwD=10 

GO  TO  2121 

GO  TO  2122 

GQ  TO  2123 

GO  TO  212a 

GQ  TO    2125 

GO  TO  2126 

GO    TU  2127 

GO  TO  212« 

GO  TO  212Q 
)  GO  TO  2130 
1  1 

*S TAR, KTND, KALLER, KSTAR 
EQ.O)  RETURN 


KSTAR, KIND, KALLER, KSTAR 

FQ.O)  RETURN 


KSTAR, KIND, KALLER, KSTAR 

EU.O)  RETURN 


KSTAR, KT NO, KALLER, KSTAR 
FQ.O)  RETUPN 


KSTAR, K I  NO, KALLER, NAME, KSTAR 
EQ.O)  RETURN 


KSTAR, KIND, KALLER, KSTAR 

EQ.O)  RETURN 


KSTAR, KIND, KALLER, NAME, KSTAR 
EQ.O)  RETURN 


KSTAR, KALLER, MARK, KSTAR 
EQ.O)  RETURN 
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pet  r i  net  •  f  t n 


aae    1 q 


1  OP  1  WRITE (7,2lO«) 

1082  IF(MSGCKIND). 

10*3  CALL  FXIT 

1084  2129  CONTINUF 

1085  WRITE f 7,21 09) 

1086  IFCMSG(KIMl))  . 

1087  CALL  FXTT 

1088  2130  CONTINUE 

1089  WRITE (7,21  10) 

1090  IF(MSGCKIND)  . 

1091  CALL  EXIT 

1092  EMU 


Fue  Nov  27  0&:18:5S  1^7° 

KSTAR,KTND,KALLER,KSTAR 
EQ.O)  RETURN 


KSTAR,KIND,KALLER,KSTAR 

EQ.O)  RETURN 


KSTAR,KIND,KALLER,KSTAR 

EQ.O)  RETURN 
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